On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand <bertranddrouvot...@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.hay...@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
