Re: [BUG] lo_open() makes a warning/falls to an assertion

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUG] lo_open() makes a warning/falls to an assertion
Date: 2008-12-03 02:20:38
Message-ID: 20081203022038.GR5672@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > I think the solution is to have each large object have its own
> > ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
> > left in the calling query's resowner, which is not good.
>
> That's not gonna scale to transactions that touch lots of large objects
> (think pg_dump). Also it seems like it would be arbitrarily altering
> the past behavior of LOs. Why don't they just use the calling query's
> snapshot (which I think is what the historical behavior is, though I'm
> too lazy to check right now)?

Well, that's precisely the problem -- they cannot use the query snapshot
(which is what the current buggy code is doing), because the query goes
away just after calling lo_open, but the snapshot needs to survive until
after lo_close is called (or until end of xact). So the last patch I
sent deals with the problem by recording the snapshot in the
transaction's resowner instead, by momentarily setting it as current.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-03 03:32:32 Re: Erroring out on parser conflicts
Previous Message Bruce Momjian 2008-12-03 01:50:50 Re: Erroring out on parser conflicts