Re: [HACKERS] Trigger regression test output
On Thursday 03 October 2002 12:46 pm, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] 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 - NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted 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. So the regression tests weren't really testing the actually built module, so to speak. Is there a good reason to leave the NOTICE's in the expected regression output? As to the way it's built, the regression tests are built in the RPMset to allow post-install (that is, post _RPM_ install) regression testing on machines without make or compilers. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Trigger regression test output
Lamar Owen [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trigger regression test output
I said: 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. Hmm, that doesn't look that good after all: the SET causes the regression output to be cluttered with a whole *lot* of chatter, which will doubtless change constantly and break the test regularly. Plan B is to make the refint.c code emit the message at NOTICE level, but to change the contrib makefile so that REFINT_VERBOSE is defined by default (ie, you gotta edit the makefile if you don't want it). This will work nicely for the regression tests' purposes. If there is anyone out there actually using refint.c in production, they might be annoyed by the NOTICE chatter, but quite honestly I doubt anyone is --- this contrib module has long since been superseded by standard foreign-key support. Comments? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Trigger regression test output
Tom Lane wrote: I said: 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. Hmm, that doesn't look that good after all: the SET causes the regression output to be cluttered with a whole *lot* of chatter, which will doubtless change constantly and break the test regularly. Plan B is to make the refint.c code emit the message at NOTICE level, but to change the contrib makefile so that REFINT_VERBOSE is defined by default (ie, you gotta edit the makefile if you don't want it). This will work nicely for the regression tests' purposes. If there is anyone out there actually using refint.c in production, they might be annoyed by the NOTICE chatter, but quite honestly I doubt anyone is --- this contrib module has long since been superseded by standard foreign-key support. Yes, but if few people are using it, should we question whether it belongs in the standard regression tests at all? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Trigger regression test output
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This will work nicely for the regression tests' purposes. If there is anyone out there actually using refint.c in production, they might be annoyed by the NOTICE chatter, but quite honestly I doubt anyone is --- this contrib module has long since been superseded by standard foreign-key support. Yes, but if few people are using it, should we question whether it belongs in the standard regression tests at all? Well, it's not there to test itself, it's there to test trigger functionality. And, not so incidentally, to test that dynamically-loaded C functions work. I don't want to take it out. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trigger regression test output
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This will work nicely for the regression tests' purposes. If there is anyone out there actually using refint.c in production, they might be annoyed by the NOTICE chatter, but quite honestly I doubt anyone is --- this contrib module has long since been superseded by standard foreign-key support. Yes, but if few people are using it, should we question whether it belongs in the standard regression tests at all? Well, it's not there to test itself, it's there to test trigger functionality. And, not so incidentally, to test that dynamically-loaded C functions work. I don't want to take it out. Oh, interestings. Makes sense. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Trigger regression test output
Lamar Owen [EMAIL PROTECTED] writes: So the regression tests weren't really testing the actually built module, so to speak. Is there a good reason to leave the NOTICE's in the expected regression output? Yes: without them the test is less useful, because you're less certain that what happened was what was supposed to happen. As to the way it's built, the regression tests are built in the RPMset to allow post-install (that is, post _RPM_ install) regression testing on machines without make or compilers. Well, I'm about to commit a change that makes the default build of contrib/spi have the correct NOTICE output, as of 7.3. You could make the 7.2 RPMset do likewise if you wish. One thing that confuses me though is that the build options have been like this for a long time (at least since 7.1). Why haven't you seen this problem before? Did you recently change the way the RPMs build contrib? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trigger regression test output
On Thursday 03 October 2002 02:31 pm, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: One thing that confuses me though is that the build options have been like this for a long time (at least since 7.1). Why haven't you seen this problem before? Did you recently change the way the RPMs build contrib? Yes, I recently changed that to use the default make instead of the horribly cobbled thing I was using. But it broke regression, which I didn't check when I built the 7.2.2-1PGDG set (I had done a regression test with 7.2.2-0.1PGDG, which had the old kludge for contrib). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
