Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1+aTp0Kd7_TreX-a+x71pqo5mvMK1M5F5v0AC5ALUj_hw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (shveta malik <shveta.malik@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
On Fri, Feb 16, 2024 at 4:10 PM shveta malik <shveta.malik@gmail.com> wrote: > > On Thu, Feb 15, 2024 at 10:48 PM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> wrote: > > > 5 === > > > > + if (SlotSyncWorker->syncing) > > { > > - SpinLockRelease(&SlotSyncCtx->mutex); > > + SpinLockRelease(&SlotSyncWorker->mutex); > > ereport(ERROR, > > errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), > > errmsg("cannot synchronize replication slots concurrently")); > > } > > > > worth to add a test in 040_standby_failover_slots_sync.pl for it? > > It will be very difficult to stabilize this test as we have to make > sure that the concurrent users (SQL function(s) and/or worker(s)) are > in that target function at the same time to hit it. > Yeah, I also think would be tricky to write a stable test, maybe one can explore using a new injection point facility but I don't think it is worth for this error check as this appears straightforward to be broken in the future by other changes. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: