On Tue, Dec 3, 2019 at 10:10 PM Tom Lane <tgl@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
