Hi,
I'm toying around with the idea of tracking snaphots more accurately to
be able to advance Xmin for read committed transactions.
I think it's relatively easy to do it in the straightforward way, which
is to just add "destroy snapshots" in the spots where a snapshot
variable goes out of scope. However, I've been thinking in doing it in
a little more elaborate (and, AFAICS, better) way: having the
ResourceOwner code be responsible for keeping track of snapshots.
Offhand I don't see any big problem with that, althought I admit I
haven't yet tried any code. One thing that jumps at me, however, is the
handling of holdable portals.
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. Vacuum
would, of course, not be able to clean up rows needed by the portal. I
don't see this as a problem, but rather as an improvement.
Thoughts?
Also, is there anything else on the whole Snapshots-on-ResourceOwners
idea that could be a showstopper?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.