On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> Thanks for all the work that has been done on this feature, and sorry
> to have been quiet on it for so long.
Thanks for looking into this.
>
> On 9/18/23 12:22 PM, shveta malik wrote:
> > On Wed, Sep 13, 2023 at 4:48 PM Hayato Kuroda (Fujitsu)
> > <kuroda.hayato@fujitsu.com> wrote:
> >> Right, but I wanted to know why it is needed. One motivation seemed to know the
> >> WAL location of physical standby, but I thought that struct WalSnd.apply could
> >> be also used. Is it bad to assume that the physical walsender always exists?
> >>
> >
> > We do not plan to target this case where physical slot is not created
> > between primary and physical-standby in the first draft. In such a
> > case, slot-synchronization will be skipped for the time being. We can
> > extend this functionality (if needed) later.
> >
>
> I do think it's needed to extend this functionality. Having physical slot
> created sounds like a (too?) strong requirement as:
>
> - It has not been a requirement for Logical decoding on standby so that could sounds weird
> to require it for sync slot (while it's not allowed to logical decode from sync slots)
>
> - One could want to limit the WAL space used on the primary
>
> It seems that the "skipping sync as primary_slot_name not set." warning message is emitted
> every 10ms, that seems too verbose to me.
>
You are right, the warning msg is way too frequent. I will optimize it
in the next version.
thanks
Shveta
