Re: Testing LISTEN/NOTIFY more effectively

Hi,

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


> diff --git a/src/test/isolation/expected/plpgsql-toast.out b/src/test/isolation/expected/plpgsql-toast.out
> index 4341153..39a7bbe 100644
> --- a/src/test/isolation/expected/plpgsql-toast.out
> +++ b/src/test/isolation/expected/plpgsql-toast.out
> @@ -35,6 +35,7 @@ step unlock:
>  pg_advisory_unlock
>  
>  t              
> +s1: NOTICE:  x = foofoofoofo

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

Greetings,

Andres Freund