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
