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 CAA4eK1J49j5ew-Tk4Ygv0nbjurJz12kZtqjHLALFuL03NBZdsg@mail.gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Synchronizing slots from primary to standby  (shveta malik <shveta.malik@gmail.com>)
List pgsql-hackers
On Thu, Oct 26, 2023 at 5:38 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> On 10/26/23 10:40 AM, Amit Kapila wrote:
> > On Wed, Oct 25, 2023 at 8:49 PM Drouvot, Bertrand
> > <bertranddrouvot.pg@gmail.com> wrote:
> >>
> >
> > Good point, I think we should enhance the WalSndWait() logic to
> > address this case.
>
> Agree. I think it would need to take care of the new CV and probably
> provide a way for the caller to detect it stopped waiting due to the socket
> (I don't think it can find out currently).
>
> > Additionally, I think we should ensure that
> > WalSndWaitForWal() shouldn't wait twice once for wal_flush and a
> > second time for wal to be replayed by physical standby. It should be
> > okay to just wait for Wal to be replayed by physical standby when
> > applicable, otherwise, just wait for Wal to flush as we are doing now.
> > Does that make sense?
>
> Yeah, I think so. What about moving WalSndWaitForStandbyConfirmation()
> outside of WalSndWaitForWal() and call one or the other in logical_read_xlog_page()?
>

I think we need to somehow integrate the logic of both functions. Let
us see what the patch author has to say about this.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Nikita Malakhov
Date:
Subject: Re: remaining sql/json patches