[prev in list] [next in list] [prev in thread] [next in thread]
List: pgsql-bugs
Subject: Re: [BUGS] Multixact and prepared transactions
From: Heikki Linnakangas <heikki.linnakangas () enterprisedb ! com>
Date: 2009-11-23 10:10:09
Message-ID: 4B0A5F81.3060506 () enterprisedb ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic