From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ResourceOwners for Snapshots? holdable portals |
Date: | 2008-02-27 19:07:50 |
Message-ID: | 20080227190750.GB19292@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:
> > We currently just copy the portal's content into a Materialize node, and
> > let the snapshot go away at transaction's end. This works, but ISTM we
> > could improve that by keeping track of the portal's snapshot separately
> > from the transaction -- that is to say, to hang it from the portal's
> > ResourceOwner. This would allow us to avoid the Materialize node
> > altogether, and just keep the xmin back until the portal's gone.
>
> That's a pretty horrid idea: what if the query being executed by the
> portal has side-effects? You can't get away with not executing it
> to completion before you close the transaction.
Ah, excellent point -- I guess that's what I was missing.
> As far as the general point goes, I had been thinking of managing
> snapshots in a central cache, because if you want to advance xmin
> intratransaction then some piece of code has to be aware of *all* the
> open snapshots in the backend; and the ResourceOwners can't do that
> conveniently because they're fairly independent. Or were you meaning
> that you would do that and on top of it have the ResourceOwners track
> references into the cache?
Yeah, I think there needs to be a separate list either way, but having
references to it from ResourceOwners means there's no need to have extra
cleanup calls at (sub)transaction commit/abort.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-02-27 19:21:36 | Re: Required make version |
Previous Message | Neil Conway | 2008-02-27 18:58:03 | Re: proposal: plpgsql return execute ... |