Re: Usage of epoch in txid_current

On 27/03/2019 13:44, Thomas Munro wrote:
> * I tidied up the code that serialises transaction state.  It was
> already hammering round pegs into square holes, and the previous patch
> made that even worse, so I added a new struct
> SerializedTransactionState to do this properly.

Ah, good, it used to be confusing.

> I still need to look into Andres's suggestion about getting rid of
> epoch from various user interfaces and showing 64 bit numbers.  I
> should probably also find a place in the relevant README to explain
> this new scheme.  I will post follow-up patches for those.

Once we have the FullTransactionId type and basic macros in place, I'm 
sure we could tidy up a bunch of code by using them. For example, 
TransactionIdInRecentPast() in walsender.c would be simpler, if the 
caller dealt with FullTransactionIds rather than xid+epoch. But it makes 
sense to do that separately.

> +/*
> + * Advance nextFullXid to the value after a given xid.  The epoch is inferred.
> + * This must only be called during recovery or from two-phase start-up code.
> + */
> +void
> +AdvanceNextFullTransactionIdPastXid(TransactionId xid)
> +{
> +	FullTransactionId newNextFullXid;
> +	TransactionId next_xid;
> +	uint32		epoch;
> +
> +	/*
> +	 * It is safe to read nextFullXid without a lock, because this is only
> +	 * called from the startup process, meaning that no other process can
> +	 * modify it.
> +	 */
> +	Assert(AmStartupProcess());
> +

This assertion fails on WAL replay in single-user mode:

$ bin/postgres --single -D data postgres
2019-03-27 14:32:35.058 EET [32359] LOG:  database system was 
interrupted; last known up at 2019-03-27 14:32:18 EET
2019-03-27 14:32:35.144 EET [32359] LOG:  database system was not 
properly shut down; automatic recovery in progress
2019-03-27 14:32:35.148 EET [32359] LOG:  redo starts at 0/15BB7B0
TRAP: FailedAssertion("!((MyAuxProcType == StartupProcess))", File: 
"varsup.c", Line: 269)
Aborted

- Heikki