Commit ae04bf50 authored by Alvaro Herrera's avatar Alvaro Herrera

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.
parent d25367ec
......@@ -840,10 +840,7 @@ parent transaction to complete.
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
stack in memory. Clog entries are made normally. Multixact is not maintained
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.
stack in memory. Clog and multixact entries are made normally.
Subtrans is maintained during recovery but the details of the transaction
tree are ignored and all subtransactions reference the top-level TransactionId
directly. Since commit is atomic this provides correct lock wait behaviour
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment