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