Skip site navigation (1) Skip section navigation (2)

Re: Multixact and prepared transactions

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: hlinnaka(at)iki(dot)fi
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Multixact and prepared transactions
Date: 2009-11-23 10:10:09
Message-ID: 4B0A5F81.3060506@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

pgsql-bugs by date

Next:From: Nikhil SontakkeDate: 2009-11-23 12:58:45
Subject: Re: BUG #5180: How to get only User created tables by using SQLTables() in ODBC
Previous:From: MaithiliDate: 2009-11-23 09:21:34
Subject: BUG #5210: error in intidb process when installing on japanese

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group