Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
| От | Masahiko Sawada |
|---|---|
| Тема | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
| Дата | |
| Msg-id | CAD21AoAsoboLKiq+x7S395Beze3CtOxtGamV2YND52kfqw=jYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
RE: POC: enable logical decoding when wal_level = 'replica' without a server restart |
| Список | pgsql-hackers |
On Wed, Oct 15, 2025 at 3:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Oct 14, 2025 at 11:40 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Tue, Oct 14, 2025 at 2:24 AM shveta malik <shveta.malik@gmail.com> wrote: > > > > > > Thanks. I was testing slot-sync worker flow and noticed that even if > > > 'sync_replication_slots' is enabled, it takes quite some time (1-2 > > > mins) for slot sync worker to start. On noticing > > > XLOG_LOGICAL_DECODING_STATUS_CHANGE, isn't there a way to (or > > > shouldn't we) wakeup postmaster to start slotsync worker immediately? > > > > > > Logs for timestamps reference: > > > > > > 2025-10-14 14:41:32.852 IST [208475] LOG: replication slot > > > synchronization requires "effective_wal_level" >= "logical" on the > > > primary > > > 2025-10-14 14:41:32.852 IST [208475] HINT: To enable logical decoding > > > on primary, set "wal_level" >= "logical" or create at least one > > > logical slot when "wal_level" = "replica". > > > 2025-10-14 14:41:35.499 IST [208481] LOG: update logical decoding status to 1 > > > 2025-10-14 14:41:35.499 IST [208481] CONTEXT: WAL redo at 0/03000060 > > > for XLOG/LOGICAL_DECODING_STATUS_CHANGE: true > > > 2025-10-14 14:42:53.611 IST [208529] LOG: slot sync worker started > > > ------ > > > > I think that this particular situation happened because the postmaster > > was sleeping and didn't have any tasks. If a new connection comes in > > or the existing connection exits, the postmaster launches the slotsync > > worker. I believe it would not be a serious issue in practice. > > > > Right, but OTOH, do we see any harm if we wake up the postmaster on > such an event? It shouldn't happen frequently to matter either way > though. It's not harmful in practice. I've considered waking up the postmaster with a new PMSignalReason, but I thought it's overkill to introduce a new reason just to wake up the postmaster. If there is a convenient way, I'd like to use that. > > > > There was a lot of discussion regarding slotsync worker in the past, > > > please let me know if it is concluded and I missed it somehow. > > > > Since we've discussed that it's out of scope of this patch that we > > shutdown dynamically upon logical decoding status changes, even if > > logical decoding status gets disabled on the standby, the slotsync > > worker keeps working. If it gets enabled again, we don't need to wake > > up the postmaster as the slotsync worker would already be running. I > > think we can introduce more dynamic control over the slotsync worker > > in a separate patch if we need. > > > > I think it is better to stop the slotsync worker at this event because > without a patch we won't even allow the server to restart if the > wal_level on standby is less than logical. But, I agree it could be > done as a separate patch as well. Agreed. I'll implement it in a follow-up patch. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: