A 2 phase commit weirdness - Mailing list pgsql-hackers

From Alvaro Herrera
Subject A 2 phase commit weirdness
Date
Msg-id 20050526232659.GA17613@surnet.cl
Whole thread Raw
Responses Re: A 2 phase commit weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hackers,

I'm seeing the following weirdness with the 2PC patch:

alvherre=# begin;
BEGIN
alvherre=# create table a (a int);
CREATE TABLE
alvherre=# insert into a values (1);
INSERT 0 1
alvherre=# prepare transaction 'foo';
PREPARE TRANSACTION
alvherre=# select * from a;


At this point, the backend freezes.  However, if I connect in another
session and issue the same "select * from a" query, it correctly returns
"no such relation".  Now, because the backend cannot see the table
(because it was created by a transaction that is not yet committed), the
first backend shouldn't freeze but return the same "no such relation".

My guess is that the backend that created the prepared transaction has
its relcache populated with the new table's entry.  But given that we
prepared the transaction, we should forget about the table, and only
remember it when we receive the shared inval message that will get sent
when the prepared transaction is committed.


I'm wondering what should happen at prepare time so that "my own cache"
is correct.  Do I need to send the inval messages to me?  Is this even
possible?  Maybe I need to read the messages from the prepare file and
send it to me.  Any ideas?

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WAL replay failure after file truncation(?)
Next
From: Tom Lane
Date:
Subject: Re: A 2 phase commit weirdness