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

From shveta malik
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id CAJpy0uBp7Q0VkXWXDBOzsEVLgsdqnpcETVdvC3u8+D8cChxi3Q@mail.gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Oct 26, 2023 at 5:43 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

Amit, this is attempted in v27.

thanks
Shveta



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby