Обсуждение: Large Objects in serializable transaction question

I have a testprogram (using libpq) reading data from a cursor and large objects according to the result of the cursor.
Thecursor is opened in a serializable transaction. 

Just for test reasons I know tried the following:
I started the test program that reads the data from the cursor and that reads the large objects according to the result
ofthe fetch. While the test was running I now was dropping all large objects in a parallel session. Since I am using a
serializabletransaction in the test program I still should be able to read all the large objects, even if I drop them
ina parallel session. But it does not work. I get an error, that the large object can't be opened. 

I now tried the same with with two simple psql sessions. Here it works the way I expected it to.

Has anybody an explanation for that? Is it due to the libpq functions lo_open ...?

Thanks
Andreas
______________________________________________________________________________
Erster Klick - SMS versenden, zweiter Klick - die Telefonnummer im
Adressbuch speichern bei: http://freemail.web.de/features/?mc=021151

=?iso-8859-1?Q? "Andreas=20Sch=F6nbach" ?= <andreasschoenbach@web.de> writes:
> I have a testprogram (using libpq) reading data from a cursor and large objects according to the result of the
cursor.The cursor is opened in a serializable transaction. 
> Just for test reasons I know tried the following:
> I started the test program that reads the data from the cursor and that reads the large objects according to the
resultof the fetch. While the test was running I now was dropping all large objects in a parallel session. Since I am
usinga serializable transaction in the test program I still should be able to read all the large objects, even if I
dropthem in a parallel session. But it does not work. I get an error, that the large object can't be opened. 

Yeah.  The large object operations use SnapshotNow (effectively
read-committed) rather than looking at the surrounding transaction's
snapshot.  This is a bug IMHO, but no one's got round to working on
it.  (It's not entirely clear how the LO functions could access the
appropriate snapshot.)

            regards, tom lane