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