Commit 46fed80
committed
Set xl_prev correctly if replica is promoted without replaying any records
Every WAL record in Postgres has a pointer to the start of the
previous record (xl_prev). Postgres keeps track of the last record
that was written in variable in shared memory, so which is then used
on the next record to fill that field. When Postgres starts up after a
clean shutdown, the variable is initialized to point ot the checkpoint
record. If the system was not shut down cleanly, Postgres performs WAL
recovery, the variable is initialized to point to the last replayed
WAL record.
In Neon however, we can start up from any record, without performing
WAL recovery. When we do that, there is no last replayed WAL record to
initialize it from, and there's not real checkpoint record either - we
fake the variables related to starting checkpoint. The "neon signal
file" that is included in the basebackup must include an explicit LSN
to use as the xl_prev value in such cases ("PREV LSN") field, and we
use that.
However, that did not work correctly in versions 15 and above, when a
replica was promoted immediately after startup, without replaying any
records.As a result, the promoted standby wrote an end-of-WAL record
with an incorrect xl_prev field, which trips over any read replicas,
that are following across the switchover. It also trips over logical
replication across that point. Add a test and fix it.1 parent 41fb35f commit 46fed80
1 file changed
+16
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1807 | 1807 | | |
1808 | 1808 | | |
1809 | 1809 | | |
1810 | | - | |
| 1810 | + | |
| 1811 | + | |
| 1812 | + | |
| 1813 | + | |
| 1814 | + | |
| 1815 | + | |
| 1816 | + | |
| 1817 | + | |
| 1818 | + | |
| 1819 | + | |
| 1820 | + | |
| 1821 | + | |
| 1822 | + | |
| 1823 | + | |
| 1824 | + | |
| 1825 | + | |
1811 | 1826 | | |
1812 | 1827 | | |
1813 | 1828 | | |
| |||
0 commit comments