On Tue, Dec 3, 2019 at 10:10 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > In principle, the issue should not be there, because commits > 790026972 et al should have ensured that the NOTIFY protocol > message comes out before ReadyForQuery (and thus, libpq will > absorb it before PQgetResult will return NULL). I think the > timing problem --- if that's what it is --- must be on the > backend side; somehow the backend is not processing the > inbound notify queue before it goes idle. > > Hmm ... just looking at the code again, could it be that there's > no well-placed CHECK_FOR_INTERRUPTS? Andrew, could you see if > injecting one in what 790026972 added to postgres.c helps? > That is, > > /* > * Also process incoming notifies, if any. This is mostly to > * ensure stable behavior in tests: if any notifies were > * received during the just-finished transaction, they'll be > * seen by the client before ReadyForQuery is. > */ > + CHECK_FOR_INTERRUPTS(); > if (notifyInterruptPending) > ProcessNotifyInterrupt(); >
I also tried to analyze this failure and it seems this is a good bet, but I am also wondering why we have never seen such a timing issue in other somewhat similar tests. For ex., one with comment (# Cross-backend notification delivery.). Do they have a better way of ensuring that the notification will be received or is it purely coincidental that they haven't seen such a symptom? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com