"Simon Riggs" <[EMAIL PROTECTED]> writes:
> No, that would break MVCC. But we may have done lots of updates/deletes
> that are *not* visible to any Snapshot, yet are not yet removable
> because they are higher than OldestXmin but we don't know that because
> previously the Snapshot details were not available. ISTM that this
> proposal is a way of making the Snapshot limits publicly available so
> that they can be used by VACUUM.
Certainly not, unless you intend that *every* snapshot *must* be
published, which is an overhead up with which we will not put.
One pretty serious problem with the proposal as written is the part
about the sender blocking until the receiver takes the snap; that means
it's not really a "publish" in the sense that you can make it available
without worrying about exactly how many readers there might or might not
be. That alone is sufficient to kill any thought of VACUUM making use
of the info. I'd feel happier with an implementation more like prepared
transactions: you stuff the information into shared memory and it sits
there, readable by anyone, until such time as you take it down again.
Like prepared xacts, GlobalXmin calculations would need to include these
snapshots (and hence they'd limit vacuums).
A shared-memory area would have to be fixed size, but perhaps backing
files, like those used by prepared xacts, could handle the overflow for
very large xip lists. Presumably crash safety is not an issue so this
wouldn't require any complicated mechanism.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
