Update transaction README for persistent multixacts

Multixacts are now maintained during recovery, but the README didn't get
the memo.  Backpatch to 9.3, where the divergence was introduced.
This commit is contained in:
Alvaro Herrera 2014-11-28 18:06:18 -03:00
parent d25367ec4f
commit ae04bf5027

View File

@ -840,10 +840,7 @@ parent transaction to complete.
Not all transactional behaviour is emulated, for example we do not insert Not all transactional behaviour is emulated, for example we do not insert
a transaction entry into the lock table, nor do we maintain the transaction a transaction entry into the lock table, nor do we maintain the transaction
stack in memory. Clog entries are made normally. Multixact is not maintained stack in memory. Clog and multixact entries are made normally.
because its purpose is to record tuple level locks that an application has
requested to prevent other tuple locks. Since tuple locks cannot be obtained at
all, there is never any conflict and so there is no reason to update multixact.
Subtrans is maintained during recovery but the details of the transaction Subtrans is maintained during recovery but the details of the transaction
tree are ignored and all subtransactions reference the top-level TransactionId tree are ignored and all subtransactions reference the top-level TransactionId
directly. Since commit is atomic this provides correct lock wait behaviour directly. Since commit is atomic this provides correct lock wait behaviour