Heikki Linnakangas wrote: > Heikki Linnakangas wrote: >> We seem to have neglected prepared transactions in the logic that tracks >> the oldest visible multixact. OldestMemberMXactId doesn't contain >> entries for prepared transactions, so the UPDATE incorrectly considers >> the multixact as an old obsolete one. >> >> A straightforward fix is to enlarge OldestMemberMXactId to make room for >> max_prepared_transactions extra entries, and at prepare transfer the >> value of the current backend to one of those slots. > > So here's a patch doing that:
Committed. > BTW, I noticed that in deadlock.c, we reserve many working arrays of > size MaxBackends. But prepared transactions can hold locks too, and > therefore can be visited by the deadlock checker. Shouldn't we reserve > space in the arrays for prepared xacts as well? You'll be hard-pressed > to hit that in practice, given that MaxBackends includes room for > autovacuum launcher and worker too, and you'd need to have all backends > involved in the deadlock. But still. This is still pending. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
