From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Testing LISTEN/NOTIFY more effectively |
Date: | 2019-07-27 18:15:39 |
Message-ID: | 14616.1564251339@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While I'm looking at isolationtester ... my eye was immediately drawn
to this bit, because it claims to be dealing with NOTIFY messages ---
though that's wrong, it's really blocking NOTICE messages:
/*
* Suppress NOTIFY messages, which otherwise pop into results at odd
* places.
*/
res = PQexec(conns[i], "SET client_min_messages = warning;");
if (PQresultStatus(res) != PGRES_COMMAND_OK)
{
fprintf(stderr, "message level setup failed: %s", PQerrorMessage(conns[i]));
exit(1);
}
PQclear(res);
This seems to me to be a great example of terrible test design.
It's not isolationtester's job to impose a client_min_messages level
on the test scripts; if they want a non-default level, they can
perfectly well set it for themselves in their setup sections.
Furthermore, if I remove this bit, the only NOTICE messages I'm
actually seeing come from explicit RAISE NOTICE messages in the
test scripts themselves, which means this is overriding the express
intent of individual test authors. And my testing isn't detecting
any instability in when those come out, although of course the
buildfarm might have a different opinion.
So I think we should apply something like the attached, and if the
buildfarm shows any instability as a result, dealing with that by
taking out the RAISE NOTICE commands.
I'm a little inclined to remove the notice anyway in the
plpgsql-toast test, as the bulk-to-value ratio doesn't seem good.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
remove-special-suppression-of-notice-messages.patch | text/x-diff | 35.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-07-27 18:23:42 | Re: Add parallelism and glibc dependent only options to reindexdb |
Previous Message | Tom Lane | 2019-07-27 17:53:06 | Re: Testing LISTEN/NOTIFY more effectively |