Follow-up fixes for online wal_level change
Hi all,
While reviewing the online wal_level change feature (commit
67c20979ce7), I found an assertion failure during crash recovery.
Also, I noticed that pg_controldata doesn't show the logical decoding
status. Patches attached.
0001 fixes the assertion failure that happens in the following scenario:
1. Run the server with wal_level = 'replica' and create a logical
slot, which writes an XLOG_LOGICAL_DECODING_STATUS_CHANGE record that
activates logical decoding.
2. Drop the slot, and crash the server before the checkpointer
deactivates logical decoding.
3. Restart the server with wal_level = 'minimal'.
Crash recovery replays the status change record and activates logical
decoding, then UpdateLogicalDecodingStatusEndOfRecovery() fails the
assertion (Assert(!IsXLogLogicalInfoEnabled() &&
!IsLogicalDecodingEnabled())) that logical decoding is never active
with wal_level='minimal'.
I think that replaying the status change record itself is correct, as
it reflects the status at the time the record was written. The problem
is that the end-of-recovery code assumed that this cannot happen,
instead of adjusting the status. Therefore, the fix removes the
wal_level='minimal' special case from
UpdateLogicalDecodingStatusEndOfRecovery() so that it recomputes the
status as usual.
0002 adds the logical decoding status stored in the checkpoint record
to the pg_controldata output, which I found useful while investigating
the above issue.
Both patches are intended to be backpatched to v19.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Attachments:
v1-0001-Correct-logical-decoding-status-at-end-of-recover.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Correct-logical-decoding-status-at-end-of-recover.patchDownload+9-12
v1-0002-pg_controldata-Show-logical-decoding-status.patchtext/x-patch; charset=US-ASCII; name=v1-0002-pg_controldata-Show-logical-decoding-status.patchDownload+2-1
On 7/16/2026 8:09 AM, Masahiko Sawada wrote:
Hi all,
While reviewing the online wal_level change feature (commit
67c20979ce7), I found an assertion failure during crash recovery.
Also, I noticed that pg_controldata doesn't show the logical decoding
status. Patches attached.0001 fixes the assertion failure that happens in the following scenario:
1. Run the server with wal_level = 'replica' and create a logical
slot, which writes an XLOG_LOGICAL_DECODING_STATUS_CHANGE record that
activates logical decoding.
2. Drop the slot, and crash the server before the checkpointer
deactivates logical decoding.
3. Restart the server with wal_level = 'minimal'.
I can reproduce this crash following above procedure. But in step 3, I also needed to set max_wal_senders=0, otherwise the serve failed to start with error: FATAL: WAL streaming ("max_wal_senders" > 0) requires "wal_level" to be "replica" or “logical".
Crash recovery replays the status change record and activates logical
decoding, then UpdateLogicalDecodingStatusEndOfRecovery() fails the
assertion (Assert(!IsXLogLogicalInfoEnabled() &&
!IsLogicalDecodingEnabled())) that logical decoding is never active
with wal_level='minimal'.I think that replaying the status change record itself is correct, as
it reflects the status at the time the record was written. The problem
is that the end-of-recovery code assumed that this cannot happen,
instead of adjusting the status. Therefore, the fix removes the
wal_level='minimal' special case from
UpdateLogicalDecodingStatusEndOfRecovery() so that it recomputes the
status as usual.0002 adds the logical decoding status stored in the checkpoint record
to the pg_controldata output, which I found useful while investigating
the above issue.Both patches are intended to be backpatched to v19.
Regards,
Both 0001 and 0002 LGTM.
Regards,
Guoqing Yang