Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id CAA4eK1+aTp0Kd7_TreX-a+x71pqo5mvMK1M5F5v0AC5ALUj_hw@mail.gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Synchronizing slots from primary to standby
List 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 by date:

Previous
From: vignesh C
Date:
Subject: Re: pg_upgrade and logical replication
Next
From: Bharath Rupireddy
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible