Trigger regression test output

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Trigger regression test output
Дата
Msg-id 8970.1033663569@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: v7.2.3 - tag'd, packaged ... need it checked ...  (Lamar Owen <lamar.owen@wgcr.org>)
Ответы Re: Trigger regression test output  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Trigger regression test output  (Lamar Owen <lamar.owen@wgcr.org>)
Список 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 по дате отправления:

Предыдущее
От: Manfred Koizar
Дата:
Сообщение: Re: [GENERAL] Large databases, performance
Следующее
От: Manfred Koizar
Дата:
Сообщение: Re: Large databases, performance