Commit866c6ab

committed

Update transaction README for persistent multixacts

Multixacts are now maintained during recovery, but the README didn't getthe memo. Backpatch to 9.3, where the divergence was introduced.

1 parent19b1511 commit866c6abCopy full SHA for 866c6ab

File tree

-4

lines changed

-4

lines changed

Lines changed: 1 addition & 4 deletions

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

Comments

(0)