Re: Coding in WalSndWaitForWal - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Coding in WalSndWaitForWal
Date
Msg-id CAA4eK1L+U4J32h7_=4cWWMR1L7qPoXi9C+VhQRimbC3jEzL0wg@mail.gmail.com
Whole thread Raw
In response to Re: Coding in WalSndWaitForWal  (Andres Freund <andres@anarazel.de>)
Responses Re: Coding in WalSndWaitForWal  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Wed, Nov 13, 2019 at 12:57 AM Andres Freund <andres@anarazel.de> wrote:
>
> On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
>
> >       /* Get a more recent flush pointer. */
> >       if (!RecoveryInProgress())
> >               RecentFlushPtr = GetFlushRecPtr();
> >       else
> >               RecentFlushPtr = GetXLogReplayRecPtr(NULL);
> >
> > +     if (loc <= RecentFlushPtr)
> > +     {
> > +             SetLatch(MyLatch);
> > +             return RecentFlushPtr;
> > +     }
>
> Hm. I'm doubtful this is a good idea - it essentially means we'd not
> check for interrupts, protocol replies, etc. for an unbounded amount of
> time.
>

I think this function (WalSndWaitForWal) will be called from
WalSndLoop which checks for interrupts and protocol replies, so it
might not miss checking those things in that context.  In which case
it will miss to check those things for an unbounded amount of time?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_waldump and PREPARE
Next
From: Amit Kapila
Date:
Subject: Re: PHJ file leak.