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
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 |