Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1hrSXt-0002po-9o
	for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jul 2019 19:39:57 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1hrSXs-0004u8-2v
	for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jul 2019 19:39:56 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1hrSXr-0004tx-R8
	for pgsql-hackers@lists.postgresql.org; Sat, 27 Jul 2019 19:39:55 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1hrSXp-0006Id-Ex
	for pgsql-hackers@lists.postgresql.org; Sat, 27 Jul 2019 19:39:55 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x6RJdiK1013345;
	Sat, 27 Jul 2019 15:39:44 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org, Peter Geoghegan <pg@bowt.ie>
Subject: Re: Testing LISTEN/NOTIFY more effectively
In-reply-to: <20190727185502.bciewsyxz642hyq6@alap3.anarazel.de>
References: <31304.1564246011@sss.pgh.pa.us>
 <20190727174202.jiwr4jgp3x7gvp22@alap3.anarazel.de>
 <5720.1564249986@sss.pgh.pa.us> <14616.1564251339@sss.pgh.pa.us>
 <20190727185502.bciewsyxz642hyq6@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 27 Jul 2019 11:55:02 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13343.1564256384.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 27 Jul 2019 15:39:44 -0400
Message-ID: <13344.1564256384@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2019-07-27 14:15:39 -0400, Tom Lane wrote:
>> 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.

> +1

>> diff --git a/src/test/isolation/expected/insert-conflict-specconflict.o=
ut b/src/test/isolation/expected/insert-conflict-specconflict.out
>> index 5726bdb..20cc421 100644
>> --- a/src/test/isolation/expected/insert-conflict-specconflict.out
>> +++ b/src/test/isolation/expected/insert-conflict-specconflict.out
>> @@ -13,7 +13,11 @@ pg_advisory_locksess           lock
>> step controller_show: SELECT * FROM upserttest;
>> key            data           =

>> =

>> +s1: NOTICE:  called for k1
>> +s1: NOTICE:  blocking 3
>> step s1_upsert: INSERT INTO upserttest(key, data) VALUES('k1', 'inserte=
d s1') ON CONFLICT (blurt_and_lock(key)) DO UPDATE SET data =3D upserttest=
.data || ' with conflict update s1'; <waiting ...>
>> +s2: NOTICE:  called for k1
>> +s2: NOTICE:  blocking 3

> Hm, that actually makes the test - which is pretty complicated - easier
> to understand.

Unfortunately, I just found out that on a slow enough machine
(prairiedog's host) there *is* some variation in when that test's
notices come out.  I am unsure whether that's to be expected or
whether there's something wrong there --- Peter, any thoughts?

What I will do for the moment is remove the client_min_messages=3DWARNING
setting from isolationtester.c and instead put it into
insert-conflict-specconflict.spec, which seems like a saner
way to manage this.  If we can get these messages to appear
stably, we can just fix that spec file.

>> +s1: NOTICE:  x =3D foofoofoofo

> Yea, there indeed does not not much point in this.

Maybe we could just log the lengths of the strings... if there's
anything broken, we could expect that the decompressed output
would be a different length.

			regards, tom lane