Trigger regression test output - Mailing list pgsql-hackers

From Tom Lane
Subject Trigger regression test output
Date
Msg-id 8970.1033663569@sss.pgh.pa.us
Whole thread Raw
In response to Re: v7.2.3 - tag'd, packaged ... need it checked ...  (Lamar Owen <lamar.owen@wgcr.org>)
Responses Re: Trigger regression test output  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Trigger regression test output  (Lamar Owen <lamar.owen@wgcr.org>)
List pgsql-hackers
Lamar Owen <lamar.owen@wgcr.org> writes:
> Builds fine here for RPM usage.  Got an odd diff in the triggers regression 
> test: did we drop a NOTICE?   If so, the regression output should probably 
> have been changed too. The diff:
> *** ./expected/triggers.out     Sat Jan 15 14:18:23 2000
> --- ./results/triggers.out      Thu Oct  3 00:16:09 2002
> ***************
> *** 75,91 ****
>   insert into fkeys values (60, '6', 4);
>   ERROR:  check_fkeys_pkey2_exist: tuple references non-existing key in fkeys2
>   delete from pkeys where pkey1 = 30 and pkey2 = '3';
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
>   ERROR:  check_fkeys2_fkey_restrict: tuple referenced in fkeys
>   delete from pkeys where pkey1 = 40 and pkey2 = '4';
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
>   update pkeys set pkey1 = 7, pkey2 = '70' where pkey1 = 50 and pkey2 = '5';
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
>   ERROR:  check_fkeys2_fkey_restrict: tuple referenced in fkeys
>   update pkeys set pkey1 = 7, pkey2 = '70' where pkey1 = 10 and pkey2 = '1';
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
> - NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
>   DROP TABLE pkeys;
>   DROP TABLE fkeys;
>   DROP TABLE fkeys2;
> --- 75,85 ----

After looking into this I have a theory about the cause: you must have
built the contrib/spi/refint.c module without -DREFINT_VERBOSE.  That
flag is required to pass the regression tests, because it controls
output of this debug notice.  The normal build procedure for the
regression tests does cause this to happen, but if you'd previously
built the contrib subdirectory with default switches, I think the
regress tests would use the existing refint.o and get a failure.

This seems a tad undesirable now that I look at it.  I don't want to
mess with 7.2.3, but for 7.3 I think we should try to make the
regression test work correctly with a default build of the contrib
module.

As of CVS tip, the notice isn't appearing in the regression test output
at all, because the elog was changed to DEBUG3 which is below the
default message threshold.  This is certainly not desirable since it
reduces the specificity of the test.

I am inclined to have the refint.c code emit the notice unconditionally
at DEBUG1 level, and then add a "SET client_min_messages = DEBUG1" in
the triggers regression test to ensure the notice will appear.

Any objections?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: [GENERAL] Large databases, performance
Next
From: Manfred Koizar
Date:
Subject: Re: Large databases, performance