Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster