Skip to content

Commit ae04bf5

Browse files
committed
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.
1 parent d25367e commit ae04bf5

File tree

1 file changed

+1
-4
lines changed
  • src/backend/access/transam

1 file changed

+1
-4
lines changed

src/backend/access/transam/README

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -840,10 +840,7 @@ parent transaction to complete.
840840

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

0 commit comments

Comments
 (0)