Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The part of this that would actually be useful to put in core is >> maintaining a 64-bit XID counter, ie, keep an additional counter that >> bumps every time XID wraps around. This cannot be done very well from >> outside core but it would be nearly trivial, and nearly free, to add >> inside. Everything else in the patch could be done just as well as an >> extension datatype. >> >> (I wouldn't do it like this though --- TransactionIdAdvance itself is >> the place to bump the secondary counter.)
> Agreed. I reconsidered after trying to do it that way --- although fixing TransactionIdAdvance itself to maintain a 2-word counter isn't hard, there are a whole lot of other places that can advance nextXid, mostly bits like this in WAL recovery: /* Make sure nextXid is beyond any XID mentioned in the record */ max_xid = xid; for (i = 0; i < xlrec->nsubxacts; i++) { if (TransactionIdPrecedes(max_xid, sub_xids[i])) max_xid = sub_xids[i]; } if (TransactionIdFollowsOrEquals(max_xid, ShmemVariableCache->nextXid)) { ShmemVariableCache->nextXid = max_xid; TransactionIdAdvance(ShmemVariableCache->nextXid); } We could hack all these places to know about maintaining an XID-epoch value, but it's not looking like a simple single-place-to-touch fix :-( So I'm now agreeing that the approach of maintaining an epoch counter in checkpoints is best after all. That will work so long as the system doesn't exceed 4G transactions between checkpoints ... and you'd have a ton of other problems before that, so this restriction does not bother me. Putting this in the core code still beats the alternatives available to non-core code because of the impossibility of being sure you get control on any fixed schedule, not to mention considerations of what happens during WAL replay and PITR. There's still a lot more cruft in the submitted patch than I think belongs in core, but I'll work on extracting something we can apply. There was some worry upthread about whether Slony would actually use this in the near future, but certainly if we don't put it in then they'll *never* be able to use it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org