agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix race condition when enabling logical decoding concurrently. 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix race condition when enabling logical decoding concurrently. @ 2026-07-27 16:12 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Masahiko Sawada @ 2026-07-27 16:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix race condition when enabling logical decoding concurrently. With wal_level = 'replica', logical decoding is enabled on demand when the first logical replication slot is created: When enabling logical decoding, EnableLogicalDecoding() flips the shared logical_decoding_enabled flag and writes an XLOG_LOGICAL_DECODING_STATUS_CHANGE record so that standbys follow the status change. The initial "already enabled?" check and the WAL record write happen under two separate acquisitions of LogicalDecodingControlLock, since the lock must be released while waiting for the ProcSignalBarrier: processes absorbing the barrier acquire the same lock in shared mode. Consequently, if two backends concurrently created the first logical slots, both could pass the initial check and both write a status-change record. The redundant record lands after the decoding start point already reserved by the other backend's slot, so decoding that slot processes the record and fails with "unexpected logical decoding status change", as xlog_decode() assumes that no such record can appear within the WAL range any slot decodes. Fix by re-checking the status after re-acquiring the lock, so that only the backend that actually performs the disabled->enabled transition writes the WAL record. Reported-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Author: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://postgr.es/m/CAFC+b6oYzmAgp7F0ivrhfZT46-CjvCTrU9pWuMNcem-52YjOTw@mail.gmail.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/0fd30e2119ede879080cef426abf4f9b304e3f51 Modified Files -------------- src/backend/replication/logical/logicalctl.c | 11 +++++ src/test/recovery/t/051_effective_wal_level.pl | 61 ++++++++++++++++++++++++-- 2 files changed, 69 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix race condition when enabling logical decoding concurrently. @ 2026-07-27 16:12 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Masahiko Sawada @ 2026-07-27 16:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix race condition when enabling logical decoding concurrently. With wal_level = 'replica', logical decoding is enabled on demand when the first logical replication slot is created: When enabling logical decoding, EnableLogicalDecoding() flips the shared logical_decoding_enabled flag and writes an XLOG_LOGICAL_DECODING_STATUS_CHANGE record so that standbys follow the status change. The initial "already enabled?" check and the WAL record write happen under two separate acquisitions of LogicalDecodingControlLock, since the lock must be released while waiting for the ProcSignalBarrier: processes absorbing the barrier acquire the same lock in shared mode. Consequently, if two backends concurrently created the first logical slots, both could pass the initial check and both write a status-change record. The redundant record lands after the decoding start point already reserved by the other backend's slot, so decoding that slot processes the record and fails with "unexpected logical decoding status change", as xlog_decode() assumes that no such record can appear within the WAL range any slot decodes. Fix by re-checking the status after re-acquiring the lock, so that only the backend that actually performs the disabled->enabled transition writes the WAL record. Reported-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Author: Srinath Reddy Sadipiralla <srinath2133@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://postgr.es/m/CAFC+b6oYzmAgp7F0ivrhfZT46-CjvCTrU9pWuMNcem-52YjOTw@mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/99e47536bbf1a165f5dc8d504f928821ebc8df6a Modified Files -------------- src/backend/replication/logical/logicalctl.c | 11 +++++ src/test/recovery/t/051_effective_wal_level.pl | 61 ++++++++++++++++++++++++-- 2 files changed, 69 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-27 16:12 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-27 16:12 pgsql: Fix race condition when enabling logical decoding concurrently. Masahiko Sawada <msawada@postgresql.org> 2026-07-27 16:12 pgsql: Fix race condition when enabling logical decoding concurrently. Masahiko Sawada <msawada@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox