Re: Synchronizing slots from primary to standby
От | shveta malik |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAJpy0uBYJh+6vsX2VnecZvc=TUFMY93O9Pob07VzsQQV3cGBWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (shveta malik <shveta.malik@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
Re: Synchronizing slots from primary to standby Re: Synchronizing slots from primary to standby Re: Synchronizing slots from primary to standby Re: Synchronizing slots from primary to standby Re: Synchronizing slots from primary to standby |
Список | pgsql-hackers |
On Wed, Dec 6, 2023 at 4:28 PM shveta malik <shveta.malik@gmail.com> wrote: > > On Wed, Dec 6, 2023 at 3:00 PM Drouvot, Bertrand > <bertranddrouvot.pg@gmail.com> wrote: > > > > Hi, > > > > On 12/6/23 7:18 AM, shveta malik wrote: > > > On Wed, Dec 6, 2023 at 10:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > >> > > >> I feel that is indirectly relying on the fact that the primary won't > > >> advance logical slots unless physical standby has consumed data. > > > > > > Yes, that is the basis of this discussion. > > > > Yes. > > > > > But now on rethinking, if > > > the user has not set 'standby_slot_names' on primary at first pace, > > > then even if walreceiver on standby is down, slots on primary will > > > keep on advancing > > > > Oh right, good point. > > > > > and thus we need to sync. > > > > Yes and I think our current check "XLogRecPtrIsInvalid(WalRcv->latestWalEnd)" > > in synchronize_slots() prevents us to do so (as I think WalRcv->latestWalEnd > > would be invalid for a non started walreceiver). > > > > But I think we do not need to deal with the case that walreceiver is > not started at all on standby. It is always started. Walreceiver not > getting started or down for long is a rare scenario. We have other > checks too for 'latestWalEnd' in slotsync worker and I think we should > retain those as is. > > > > We have no check currently > > > that mandates users to set standby_slot_names. > > > > > > > Yeah and OTOH unset standby_slot_names is currently the only > > way for users to "force" advance failover slots if they want to (in case > > say the standby is down for a long time and they don't want to block logical decoding > > on the primary) as we don't provide a way to alter the failover property > > (unless connecting with replication which sounds more like a hack). > > > > yes, right. > > > >> Now, > > >> it is possible that slot-sync worker lags behind and still needs to > > >> sync more data for slots in which it makes sense for slot-sync worker > > >> to be alive. > > > > Right. > > > > Regards, > > > > -- > > Bertrand Drouvot > > PostgreSQL Contributors Team > > RDS Open Source Databases > > Amazon Web Services: https://aws.amazon.com PFA v43, changes are: v43-001: 1) Support of 'failover' dump in pg_dump. It was missing earlier. v43-002: 1) Slot-sync worker now checks validity of primary_slot_name by connecting to primary, once during its start and later if primary_slot_name GUC is changed. 2) Doc improvement (see logicaldecoding.sgml). More details on overall slot-sync feature is added along with Nisha's comment of documenting disabled-subscription behaviour wrt to synced slots. thanks Shveta
Вложения
В списке pgsql-hackers по дате отправления: