From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Testing LISTEN/NOTIFY more effectively
Date: Sat, 27 Jul 2019 19:45:15 -0400
Message-ID: <13589.1564271115@sss.pgh.pa.us> (raw)
In-Reply-To: <10166.1564270037@sss.pgh.pa.us>
References: <31304.1564246011@sss.pgh.pa.us>
<20190727174202.jiwr4jgp3x7gvp22@alap3.anarazel.de>
<5720.1564249986@sss.pgh.pa.us>
<29162.1564266052@sss.pgh.pa.us>
<20190727231826.g34yqkzj53ey46tl@alap3.anarazel.de>
<10166.1564270037@sss.pgh.pa.us>
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> Hm. I wonder if all that's happening with prairedog is that the notice
>> is sent a bit later. I think that could e.g. conceivably happen because
>> it TCP_NODELAY isn't supported on prariedog? Or just because the machine
>> is very slow?
> The notices (not notifies) are coming out in the opposite order from
> expected. I haven't really thought hard about what's causing that;
> it seems odd, because isolationtester isn't supposed to give up waiting
> for a session until it's visibly blocked according to pg_locks. Maybe
> it needs to recheck for incoming data once more after seeing that?
Ah-hah, that seems to be the answer. With the attached patch I'm
getting reliable-seeming passes on prairiedog.
regards, tom lane
Attachments:fix-notice-before-waiting.patch (text/x-diff, 1.1K) downloaddiff --git a/src/test/isolation/isolationtester.c b/src/test/isolation/isolationtester.cindex 6ab19b1..e97fef1 100644
*** a/src/test/isolation/isolationtester.c
--- b/src/test/isolation/isolationtester.c
*************** try_complete_step(Step *step, int flags)
*** 752,757 ****
--- 752,777 ----
if (waiting) /* waiting to acquire a lock */
{
+ /*+ * Since it takes time to perform the lock-check query,+ * some data --- notably, NOTICE messages --- might have+ * arrived since we looked. We should do PQconsumeInput+ * to process any such messages, and we might as well then+ * check PQisBusy, though it's unlikely to succeed.+ */+ if (!PQconsumeInput(conn))+ {+ fprintf(stderr, "PQconsumeInput failed: %s\n",+ PQerrorMessage(conn));+ exit(1);+ }+ if (!PQisBusy(conn))+ break;+ + /*+ * conn is still busy, so conclude that the step really is+ * waiting.+ */
if (!(flags & STEP_RETRY))
printf("step %s: %s <waiting ...>\n",
step->name, step->sql);
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: tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: Testing LISTEN/NOTIFY more effectively
In-Reply-To: <13589.1564271115@sss.pgh.pa.us>
* 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