Thread: v7.2.3 - tag'd, packaged ... need it checked ...

v7.2.3 - tag'd, packaged ... need it checked ...

From
"Marc G. Fournier"
Date:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?





Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Tom Lane
Date:
"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


Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Lamar Owen
Date:
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
keyin 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
referencedin 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
referencedin 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


Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Lamar Owen
Date:
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


Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Tom Lane
Date:
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


Trigger regression test output

From
Tom Lane
Date:
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


Re: Trigger regression test output

From
Tom Lane
Date:
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


Re: Trigger regression test output

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: Trigger regression test output

From
Tom Lane
Date:
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.
        regards, tom lane


Re: Trigger regression test output

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: Trigger regression test output

From
Lamar Owen
Date:
On 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


Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Lamar Owen
Date:
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


Re: Trigger regression test output

From
Tom Lane
Date:
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


Re: Trigger regression test output

From
Lamar Owen
Date:
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


Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Peter Eisentraut
Date:
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



Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
"Marc G. Fournier"
Date:
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)?




Re: v7.2.3 - tag'd, packaged ... need it checked ...

From
Peter Eisentraut
Date:
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