Re: Windows buildfarm members vs. new async-notify isolation test

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