On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > Thanks for all the work that has been done on this feature, and sorry > to have been quiet on it for so long. > > 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) >
There is a difference here that we also need to prevent removal of rows required by sync_slots. That could be achieved by physical slot (and hot_standby_feedback). So, having a requirement to have physical slot doesn't sound too unreasonable to me. Otherwise, we need to invent some new mechanism of having some sort of placeholder slot to avoid removal of required rows. I guess we can always extend the functionality in later version as Shveta mentioned. Now, if we have somewhat simpler way to achieve prevention of removal of rows then it is fine otherwise let's focus on getting other parts correct considering this is already a reasonably big and complex patch. Thanks for looking into this work and your feedback will definetely help in moving this work forward. -- With Regards, Amit Kapila.
