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
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]surnet.cl>)
"No single strategy is always right (Unless the boss says so)"
In response to
pgsql-hackers by date
|Next:||From: Mark Kirkwood||Date: 2005-05-31 01:07:15|
|Subject: Re: [HACKERS] pg_buffercache causes assertion failure|
|Previous:||From: Tom Lane||Date: 2005-05-31 00:08:59|
|Subject: Re: [HACKERS] pg_buffercache causes assertion failure |