[HACKERS] Fast promotion failure

[Heikki Linnakangas]

While testing the bug from the "Assertion failure at standby promotion", I bumped into a different bug in fast promotion. When the first checkpoint after fast promotion is performed, there is no guarantee that the checkpointer process is running with the correct, new, ThisTimeLineID. In CreateCheckPoint(), we have this:

        /*
         * An end-of-recovery checkpoint is created before anyone is allowed to
         * write WAL. To allow us to write the checkpoint record, temporarily
         * enable XLogInsertAllowed.  (This also ensures ThisTimeLineID is
         * initialized, which we need here and in AdvanceXLInsertBuffer.)
         */
        if (flags & CHECKPOINT_END_OF_RECOVERY)
                LocalSetXLogInsertAllowed();

- Heikki

That ensures that ThisTimeLineID is updated when performing an end-of-recovery checkpoint, but it doesn't get executed with fast promotion. The consequence is that the checkpoint is created with the old timeline, and subsequent recovery from it will fail. I ran into this with the attached script. It sets up a master (M), a standby (B), and a cascading standby (C). I'm not sure why, but when I tried to simplify the script by removing the cascading standby, it started to work. The bug occurs in standby B, so I'm not sure why the presence of the cascading standby makes any difference. Maybe it just affects the timing.

fast-promotion-bug.sh
Description: application/shellscript

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers