A 2 phase commit weirdness

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)