Обсуждение: Large objects and savepoints - Snapshot reference leak

Поиск
Список
Период
Сортировка

Large objects and savepoints - Snapshot reference leak

От
Andreas Lubensky
Дата:
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?

--
with best regards,

Andreas Lubensky

Software Engineer



Re: Large objects and savepoints - Snapshot reference leak

От
Pavel Stehule
Дата:

Hello

This bug was fixed few months by Heikki

Regards

Pavel

Dne 31.1.2014 17:35 "Andreas Lubensky" <lubensky@cognitec.com> napsal(a):
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?

--
with best regards,

Andreas Lubensky

Software Engineer



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: Large objects and savepoints - Snapshot reference leak

От
Alvaro Herrera
Дата:
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@iki.fi>
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


Re: Large objects and savepoints - Snapshot reference leak

От
Andreas Lubensky
Дата:
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@iki.fi>
> 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