Hi hackers,
During replication, when a new timeline is detected, PostgreSQL creates a new zero-filled WAL segment on the new timeline instead of copying the partial segment from the previous timeline. This diverges from the behavior during timeline switches at startup.
This discrepancy can cause problems — especially under slow replication. Consider the following scenario:
last record in TLI | | timeline switch point
v v
|-----TLI N---------------|0000000000000000000
|
|-----TLI N+1--00000000000|0000000000000000000
If a standby is promoted before the WAL segment containing the last record of the previous timeline has been fully copied to the new timeline, startup may fail. We have observed this in production, where recovery aborts with "PANIC: invalid magic number 0000 in WAL segment ..."
I’ve attached:
* a patch and a TAP test that reproduce the issue;
* a draft patch that, on timeline switch during recovery, copies the remainder of the current WAL segment from the old timeline — matching the behavior used after crash recovery at startup.
All existing regression tests pass with the patch applied, but I plan to add more targeted test cases.
I’d appreciate your feedback. In particular:
* Is this behavior (not copying the segment during replication) intentional?
* Are there edge cases I might be overlooking?
---
Best wishes,
Alena Vinter