Re: Synchronizing slots from primary to standby
От | shveta malik |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAJpy0uBaF-LSEAQsydpoEPsO8vjQS4Jcj7sHxXmSYs7VcCP3zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: