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. Not to mention that
it depends on locks not just snapshots.
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?
regards, tom lane
