Thanks Alvaro, that is good to know. At the moment we are stuck with version 9.1.9 and have to stay there at least for Linux. But do I understand correctly, that the warning can be ignored for the moment? On Fri, 2014-01-31 at 15:15 -0300, Alvaro Herrera wrote: > Andreas Lubensky wrote: > > Hi, > > > > I'm trying to read/write large objects via libpq. I encapsulated the > > operations in a transaction but I wanted to put a savepoint before doing > > any operations, so I can do a rollback in case anything fails without > > breaking the current transaction. Now, when sth. actually fails and the > > transaction is rolled back to the savepoint, the next commit results in > > a warning: > > Snapshot reference leak: Snapshot 0xb5e4b0 still referenced > > I'm not sure what to make of that. Can it be ignored? Is rolling back > > large object operations not possible? > > What vresion are you running? I wonder if this can be attributed to a > bug fixed by this commit: > > Author: Heikki Linnakangas <heikki.linnakangas@xxxxxx> > Branch: master [357f75213] 2013-09-30 12:53:14 +0300 > Branch: REL9_3_STABLE Release: REL9_3_1 [f609d0743] 2013-09-30 12:53:56 +0300 > Branch: REL9_2_STABLE Release: REL9_2_5 [fc7a38f32] 2013-09-30 12:54:37 +0300 > Branch: REL9_1_STABLE Release: REL9_1_10 [cd6c03b5c] 2013-09-30 12:55:57 +0300 > Branch: REL9_0_STABLE Release: REL9_0_14 [c5c87f065] 2013-09-30 12:58:51 +0300 > Branch: REL8_4_STABLE Release: REL8_4_18 [fef01d419] 2013-09-30 13:00:00 +0300 > > Fix snapshot leak if lo_open called on non-existent object. > > lo_open registers the currently active snapshot, and checks if the > large object exists after that. Normally, snapshots registered by lo_open > are unregistered at end of transaction when the lo descriptor is closed, but > if we error out before the lo descriptor is added to the list of open > descriptors, it is leaked. Fix by moving the snapshot registration to after > checking if the large object exists. > > Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration > system was introduced in 8.4, so prior versions are not affected (and not > supported, anyway). > > -- > Álvaro Herrera http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > -- with best regards, Andreas Lubensky Software Engineer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general