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

Re: A 2 phase commit weirdness

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A 2 phase commit weirdness
Date: 2005-05-31 00:14:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, May 27, 2005 at 11:12:06AM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > Looking at the sequence, at least the relcache init file stuff looks if 
> > not broken at least a bit heavy-handed...
> I was planning to change that ;-) ... using separate 2PC action records
> for the relcache init file actions would make it much better.

Hum, do you mean separate for 2PC only, or make'em completely separate
invalidation messages?

I fixed the problem I had -- it was very easy to make the messages get
processed locally.  However strangeness can still happen.  Consider:

create table foo ();

drop table foo;
prepare transaction 'foo';

Now any backend that tries to access table foo will block, because the
'foo' prepared transaction has acquired a lock on it.  However the table
is still visible in the catalogs, as it should be.  It can easily be
awakened by other backend doing

commit transaction 'foo';

But at awakening, the user will get this:

ERROR:  relation 66002 deleted while still in use

This is ugly -- I don't think there is a way to get out of it.

Unrelated question: is it intended that the prepared transactions are
visible cross-database through pg_prepared_xacts?

Alvaro Herrera (<alvherre[a]>)
"No single strategy is always right (Unless the boss says so)"
                                                  (Larry Wall)

In response to


pgsql-hackers by date

Next:From: Mark KirkwoodDate: 2005-05-31 01:07:15
Subject: Re: [HACKERS] pg_buffercache causes assertion failure
Previous:From: Tom LaneDate: 2005-05-31 00:08:59
Subject: Re: [HACKERS] pg_buffercache causes assertion failure

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