Remove the end-of-recovery checkpoint in all cases.
authorRobert Haas <rhaas@postgresql.org>
Mon, 18 Apr 2022 19:40:12 +0000 (15:40 -0400)
committerRobert Haas <rhaas@postgresql.org>
Tue, 19 Apr 2022 12:26:12 +0000 (08:26 -0400)
commit59b804658ff9fc97964a9296b9612d5039d5a3f3
treea02080c5092f34c351ceca0d9280fec1d423858c
parenta62bff74b135b191de0417d1cc8ec52f144c8fe7
Remove the end-of-recovery checkpoint in all cases.

For many years, we've been issuing a special end-of-recovery WAL
record rather than performing an end-of-recovery checkpoint when a
standby is promoted.  This has the advantage of speeding up promotion.
However, it's advantageous to do this at the end of crash recovery as
well, and for the same reasons.  Plus, it's actually simpler this way,
because having only one way to do something rather than two means we
need less code.

We now always request a checkpoint at the end of recovery. If we
crash again before that checkpoint completes, recovery will begin
from the previous checkpoint that we performed - or replayed. This
behavior is not new as far as archive recovery is concerned, but now
it can also happen for crash recovery.

At initdb time, we now initialize the nextXid counter to 4 rather
than to 3. The code for logging standby shapshots and handling them
on th standby can't handle 3, because we set latestCompleteXid =
nextXid - 1, and 2 is not a normal XID. This is arguably a preexisting
bug, but because we didn't log a standby snapshot when starting from
an end-of-recovery checkpoint, we happened not to ever hit the
problematic case.
src/backend/access/transam/xlog.c
src/backend/postmaster/checkpointer.c
src/backend/replication/logical/decode.c
src/backend/storage/buffer/bufmgr.c
src/include/access/xlog.h
src/include/access/xlog_internal.h