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
UPDATESET 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
