Re: Testing LISTEN/NOTIFY more effectively

Hi,

On 2019-07-27 15:39:44 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> >> diff --git a/src/test/isolation/expected/insert-conflict-specconflict.out 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', 'inserted s1') ON CONFLICT (blurt_and_lock(key)) DO UPDATE SET data = 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

Hm. Any chance you could show the diff? I don't immediately see why.


>  --- Peter, any thoughts?

Think that's my transgression :/


> What I will do for the moment is remove the client_min_messages=WARNING
> 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.

Makes sense.

Greetings,

Andres Freund