From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Date: | 2025-10-17 03:25:26 |
Message-ID: | CAA4eK1+_pA2gpJAWjmg3SZYZU+nx3SMGmBF+FfUpyk-Xv=ttbQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 16, 2025 at 11:10 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Oct 16, 2025 at 1:41 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
>
> Using PMSIGNAL_BACKGROUND_WORKER_CHANGE sounds mis-using since the
> slotsync worker is not a background worker nor logical decoding
> activation is not related to bgworkers.
>
> An alternative idea is to launch the slotsync worker if wal_level
> value on the standby is >=replica, that is, always launch it on the
> standby if sync_replication_slots is on. Even with and without the
> patch, we don't shutdown the slotsync worker even if logical decoding
> gets disabled on the standby.
>
Are you talking about the case when wal_level on primary has reduced
below logical and user will get the following message on standby:
"logical decoding on standby requires \"wal_level\" >= \"logical\" on
the primary"? If so, the slight difference in this case is that
standby still has wal_level logical.
>
> So it would be okay in principle to keep
> the slotsync worker running while wal_level='replica'. A drawback
> would be that users always using wal_level='replica' would
> unnecessarily launch the slotsync worker but they can turn off
> sync_replication_slots GUC parameter.
>
Right, I would prefer a new PMSIGNAL for this. But OTOH, we are not
sure how frequent or important this case is in the field, so maybe it
is not worth adding more code for it. However, we should at least add
a comment for future optimization. One semi-related point is if one
would like to write a regression test for this behaviour, the test
timing would be unpredictable.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-10-17 03:40:03 | Question for coverage report |
Previous Message | Xuneng Zhou | 2025-10-17 03:17:25 | Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs |