Re: Coding in WalSndWaitForWal

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Coding in WalSndWaitForWal
Date: 2019-11-13 08:51:13
Message-ID: CAA4eK1L+U4J32h7_=4cWWMR1L7qPoXi9C+VhQRimbC3jEzL0wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 13, 2019 at 12:57 AM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-11-13 08:52:45 Re: PHJ file leak.
Previous Message Fujii Masao 2019-11-13 08:37:45 Re: pg_waldump and PREPARE