Re: Coding in WalSndWaitForWal

At Wed, 13 Nov 2019 14:21:13 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> 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?

I think so for the first part, but I'm not sure for the second. But it
should be avoided if it can be happen.

# the walreader's callback structure makes such things less clear :p

I remember that there was a fixed bug that logical replication code
fails to send a reply for a longer time than timeout on a very fast
connection, running through a fast path without checking the need for
reply. I couldn't find where it is, though..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center