"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