Tom Lane wrote:
> What I'm envisioning is that we lose the notion of "this is a
> serializable snapshot" that that function currently has, and just
> give it the rule "if MyProc->xmin is currently zero, then set it".
> Then the only additional mechanism needed is for the snapshot
> manager to detect when all snapshots are gone and zero out
> MyProc->xmin --- that would happen sometime during command shutdown,
> and per current discussion it shouldn't need a lock.
This is all easily done -- it's just a couple of extra lines.
However I am now having a definitional problem. Perhaps it is so
obvious to everyone else that nobody bothered mentioning it. I know I
wasn't aware until I tried a simple test and found that the Xmin wasn't
advancing as I was expecting.
The problem is that we always consider every transaction's PGPROC->xid
in calculating MyProc->xmin. So if you have a long running transaction,
it doesn't matter how far beyond the snapshots are -- the value returned
by GetOldestXmin will always be at most the old transaction's Xid. Even
if that transaction cannot see the old rows because all of its snapshots
are way in the future.
As far as I can see, for the purposes of VACUUM we can remove any tuple
that was deleted after the old transaction's Xid but before that
transaction's Xmin (i.e. all of its live snapshots). This means we get
to ignore Xid in GetOldestXmin and in the TransactionXmin calculations
in GetSnapshotData. It would not surprise me, however, to find out that
I am overlooking something and this is incorrect.
Am I blind?
It is quite possible that for the other purposes that we're using Xmins
for, this is not so. If that's the case, I would argue that we would
need to introduce a separate TransactionId to keep track of, which would
retain the current semantics of Xmin, and let VACUUM use what I am
proposing. I haven't examined those other uses though.
Thoughs?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support