Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.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.
