Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to

Bruce Momjian <bruce@momjian.us> 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