Re: GiST VACUUM

On 27/06/2019 20:15, Andrey Borodin wrote:
> But I have stupid question again, about this code:
> 
>
https://github.com/x4m/postgres_g/commit/096d5586537d29ff316ca8ce074bbe1b325879ee#diff-754126824470cb8e68fd5e32af6d3bcaR417
> 
>         nextFullXid = ReadNextFullTransactionId();
>             diff = U64FromFullTransactionId(nextFullXid) -
>                 U64FromFullTransactionId(latestRemovedFullXid);
>             if (diff < MaxTransactionId / 2)
>             {
>                 TransactionId latestRemovedXid;
>                     
>                 // sleep(100500 hours); latestRemovedXid becomes xid from future
>     
>                 latestRemovedXid = XidFromFullTransactionId(latestRemovedFullXid);
>                 ResolveRecoveryConflictWithSnapshot(latestRemovedXid,
>                                                     xlrec->node);
>             }
> 
> Do we have a race condition here? Can latestRemovedXid overlap and start to be xid from future?
> I understand that it is purely hypothetical, but still latestRemovedXid is from ancient past already.

Good question. No, that can't happen, because this code is in the WAL 
redo function. In a standby, the next XID counter only moves forward 
when a WAL record is replayed that advances it, and all WAL records are 
replayed serially, so that can't happen when we're in the middle of 
replaying this record. A comment on that would be good, though.

When I originally had the check like above in the code that created the 
WAL record, it had exactly that problem, because in the master the next 
XID counter can advance concurrently.

- Heikki