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
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 |