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