At Wed, 13 Nov 2019 14:21:13 +0530, Amit Kapila <[email protected]> wrote in > On Wed, Nov 13, 2019 at 12:57 AM Andres Freund <[email protected]> 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
