v7.2.3 - tag'd, packaged ... need it checked ...
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
"Marc G. Fournier" <scrappy@hub.org> writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Sources look okay from here. Didn't look at the built-docs files.
regards, tom lane
On Wednesday 02 October 2002 11:52 pm, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Sources look okay from here. Didn't look at the built-docs files.
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 ----Tom, the timestamp and horology passes on RH 7.3 here. Which is nice. Will
try 8.0 tomorrow at work.
RPMs will be uploaded either tonight or tomorrow morning after I get to work;
it will depend on how much upload bandwidth I can get out of this dialup. It
appears to be running OK, so I may let it run.....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Thursday 03 October 2002 12:29 am, Lamar Owen wrote:
RPMs will be uploaded either tonight or tomorrow morning after I get to
work; it will depend on how much upload bandwidth I can get out of this
dialup. It appears to be running OK, so I may let it run.....
After I get to work. Too many disconnects; too low a throughput.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
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.
No, we didn't change anything, and the 7.2 regression tests passed for
me on Tuesday. Please investigate more closely.
regards, tom lane
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
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
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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Thursday 03 October 2002 12:46 pm, Tom Lane wrote:
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 - 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
On Thursday 03 October 2002 12:29 am, Lamar Owen wrote:
RPMs will be uploaded either tonight or tomorrow morning after I get to
work; it will depend on how much upload bandwidth I can get out of this
dialup. It appears to be running OK, so I may let it run.....
RPMS uploaded into the usual place, so the announcement can take that into
account, Marc.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> 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
On Thursday 03 October 2002 02:31 pm, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> 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
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Probably not, because the version number needs to be changed and they need
to be rebuilt for each release.
--
Peter Eisentraut peter_e@gmx.net
On Mon, 7 Oct 2002, Peter Eisentraut wrote:
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?Probably not, because the version number needs to be changed and they need
to be rebuilt for each release.
should I run the same 'gmake docs' then, as I've been doing for the
snapshot(s)?
Marc G. Fournier writes:
On Mon, 7 Oct 2002, Peter Eisentraut wrote:
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?Probably not, because the version number needs to be changed and they need
to be rebuilt for each release.should I run the same 'gmake docs' then, as I've been doing for the
snapshot(s)?
src/tools/RELEASE_CHANGES contains all the places where the version number
needs to be changed. (Actually, I should eliminate some of these places,
but that won't help now.) After that you can build the docs using
doc/src$ gmake postgres.tar.gz
doc/src$ mv postgres.tar.gz ..
and copy man.tar.gz from the ftp site (since it doesn't change) to doc/.
After that, 'make dist'.
--
Peter Eisentraut peter_e@gmx.net