From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
Date: Fri, 6 Dec 2019 17:11:10 -0500
Message-ID: <e1eb7182-a487-42f1-e113-4e5758e8ceef@2ndQuadrant.com> (raw)
In-Reply-To: <CAA4eK1+HOFzs=-MHDz6ef936KuuHJBxZbHEi7xt9TBqgHNO9GQ@mail.gmail.com>
References: <32745.1575303812@sss.pgh.pa.us>
<7221b3b4-fc7f-404d-5cf6-830d3aa6800d@2ndQuadrant.com>
<362bca0b-1c1c-c760-ab19-b5d9a14c69ea@gmail.com>
<13003.1575391248@sss.pgh.pa.us>
<CAA4eK1+qevZ=sB1nW05_gkiHLWjUU0psNPiutFnQi=+aCztLXA@mail.gmail.com>
<25746.1575436347@sss.pgh.pa.us>
<CAA8=A78X-0vVd5tk7r=Z7yEWW5Vy1=46q7wjZaOa8Xaed5FooQ@mail.gmail.com>
<CAA4eK1+HOFzs=-MHDz6ef936KuuHJBxZbHEi7xt9TBqgHNO9GQ@mail.gmail.com>
On 12/5/19 4:37 AM, Amit Kapila wrote:
> On Wed, Dec 4, 2019 at 9:51 PM Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com> wrote:
>> On Wed, Dec 4, 2019 at 12:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Amit Kapila <amit.kapila16@gmail.com> writes:
>>>> On Tue, Dec 3, 2019 at 10:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>> 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?
>>>> 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?
>>> TBH, my bet is that this *won't* fix it, but it seemed like an easy
>>> thing to test. For this to fix it, you'd have to suppose that we
>>> never do a CHECK_FOR_INTERRUPTS during a COMMIT command, which is
>>> improbable at best.
>>>
>>
>> You win your bet. Tried this on frogmouth and it still failed.
>>
> IIUC, this means that commit (step l2commit) is finishing before the
> notify signal is reached that session. If so, can we at least confirm
> that by adding something like select pg_sleep(1) in that step? So,
> l2commit will be: step "l2commit" { SELECT pg_sleep(1); COMMIT; }. I
> think we can try by increasing sleep time as well to confirm the
> behavior if required.
>
Yeah, with the sleep in there the NOTIFY is seen.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andrew.dunstan@2ndquadrant.com, amit.kapila16@gmail.com, tgl@sss.pgh.pa.us, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
In-Reply-To: <e1eb7182-a487-42f1-e113-4e5758e8ceef@2ndQuadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox