Re: [HACKERS] New compile warnings for inheritance
On Wed, Dec 01, 2004 at 08:10:24PM -0700, Michael Fuhr wrote: > Don't know about Solaris 9/sparc yet -- the whole dance takes over > an hour on my (t)rusty ol' Ultra 1. Solaris 9/sparc passes all tests. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] New compile warnings for inheritance
On Wed, Dec 01, 2004 at 08:35:40PM -0500, Tom Lane wrote: > Okay, I committed some tweaks to reduce platform dependencies. I get > passes now on all three platforms I have handy. It passes on my FreeBSD 4.10-STABLE box. Don't know about Solaris 9/sparc yet -- the whole dance takes over an hour on my (t)rusty ol' Ultra 1. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New compile warnings for inheritance
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am seeing the following regression failures with CVS head and > > inheritance tests. They look like sort order problems: > > Does it go away if you initdb? I suspect the size of pg_class is a > factor in the choice of plan for that query. You seem to still be > getting the old plan ... An initdb does not change the regression failure. Sorry. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New compile warnings for inheritance
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Does it go away if you initdb? I suspect the size of pg_class is a > >> factor in the choice of plan for that query. You seem to still be > >> getting the old plan ... > > > An initdb does not change the regression failure. Sorry. > > Hmph. I'm unsure why there's a platform dependency there, but we should > probably just add an ORDER BY to suppress it. Will do. Why did it just appear? Optimizer changes in the past few days? -- 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] New compile warnings for inheritance
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Hmph. I'm unsure why there's a platform dependency there, but we should >> probably just add an ORDER BY to suppress it. Will do. > Why did it just appear? Optimizer changes in the past few days? I did just change the planner, but what I don't understand at the moment is why the results changed for me and not for you. It looks like it's not actually the join to pg_class that is determining this, but the plan used for the UPDATE just above it. That involves only freshly-created tables and so it ought to be pretty much the same planner problem for everyone. Odd. I'm building now on a Linux machine to see if I can reproduce your result when using little-endian hardware. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] New compile warnings for inheritance
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Does it go away if you initdb? I suspect the size of pg_class is a >> factor in the choice of plan for that query. You seem to still be >> getting the old plan ... > An initdb does not change the regression failure. Sorry. Hmph. I'm unsure why there's a platform dependency there, but we should probably just add an ORDER BY to suppress it. Will do. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] New compile warnings for inheritance
Neil Conway <[EMAIL PROTECTED]> writes: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> I am seeing the following regression failures with CVS head and >> inheritance tests. They look like sort order problems: > I see regression test failures in both inheritence and join (after a > fresh initdb). Attached is the regression.diffs, gzip'ed. Okay, I committed some tweaks to reduce platform dependencies. I get passes now on all three platforms I have handy. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] New compile warnings for inheritance
Neil Conway <[EMAIL PROTECTED]> writes: > I see regression test failures in both inheritence and join (after a > fresh initdb). Attached is the regression.diffs, gzip'ed. Yeah, so do I on a Linux machine. It looks like the dynamic size estimates are highlighting some platform dependencies, such as the effect of different MAXALIGN values on the costs, that we happened not to see in the regression tests before. I'm working on cleaning it up ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] New compile warnings for inheritance
On Wed, 2004-12-01 at 17:22 -0500, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am seeing the following regression failures with CVS head and > > inheritance tests. They look like sort order problems: > > Does it go away if you initdb? I suspect the size of pg_class is a > factor in the choice of plan for that query. You seem to still be > getting the old plan ... I see regression test failures in both inheritence and join (after a fresh initdb). Attached is the regression.diffs, gzip'ed. -Neil regression.diffs.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] New compile warnings for inheritance
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am seeing the following regression failures with CVS head and > inheritance tests. They look like sort order problems: Does it go away if you initdb? I suspect the size of pg_class is a factor in the choice of plan for that query. You seem to still be getting the old plan ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] New compile warnings for inheritance
I am seeing the following regression failures with CVS head and inheritance tests. They look like sort order problems: --- *** ./expected/inherit.out Wed Dec 1 16:53:51 2004 --- ./results/inherit.out Wed Dec 1 17:10:12 2004 *** *** 561,573 relname | f1 | f2 -++- bar | 4 | 4 - bar | 3 | 103 - bar | 2 | 102 bar | 1 | 101 bar2| 4 | 4 - bar2| 3 | 103 - bar2| 2 | 102 bar2| 1 | 101 (8 rows) /* Test inheritance of structure (LIKE) */ --- 561,573 relname | f1 | f2 -++- bar | 4 | 4 bar | 1 | 101 + bar | 2 | 102 + bar | 3 | 103 bar2| 4 | 4 bar2| 1 | 101 + bar2| 2 | 102 + bar2| 3 | 103 (8 rows) /* Test inheritance of structure (LIKE) */ == -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New compile warnings
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > I don't currently have the resources to clean this up properly. The > > attached patch tries to make clear in a comment what the code is doing, > > and also initializes these variables to NULL. If someone wants to take a > > stab at cleaning this up they are welcome to - I don't expect to be able > > to for quite a while. > > OK, applied. It compiles warning-free now for me (using Perl 5.8.0) FYI, I still see compile warnings. I assume they are just related to me using Perl 5.0.5 and will ignore them: gmake[2]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/test/regress' gmake[1]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/test' /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used SPI.c:59: warning: no previous prototype for `XS__elog' SPI.c:78: warning: no previous prototype for `XS__DEBUG' SPI.c:93: warning: no previous prototype for `XS__LOG' SPI.c:108: warning: no previous prototype for `XS__INFO' SPI.c:123: warning: no previous prototype for `XS__NOTICE' SPI.c:138: warning: no previous prototype for `XS__WARNING' SPI.c:153: warning: no previous prototype for `XS__ERROR' SPI.c:168: warning: no previous prototype for `XS__spi_exec_query' SPI.c:197: warning: no previous prototype for `boot_SPI' /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used -- 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 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] New compile warnings
Andrew Dunstan <[EMAIL PROTECTED]> writes: > I don't currently have the resources to clean this up properly. The > attached patch tries to make clear in a comment what the code is doing, > and also initializes these variables to NULL. If someone wants to take a > stab at cleaning this up they are welcome to - I don't expect to be able > to for quite a while. OK, applied. It compiles warning-free now for me (using Perl 5.8.0) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New compile warnings
Andrew Dunstan wrote: This message can actually be fixed with the addition of the following 2 lines to SPI.xs: *BOOT*: *items* = 0; /* avoid '*unused **variable*' warning */ Argghh!! Mozilla mailer C&P strikes again. BOOT: items = 0; /* avoid 'unused variable' warning */ cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New compile warnings
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: I am seeing the following compile warnings in CVS. I am using for perl: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: I believe these two: plperl.c:948: warning: `ret_hv' might be used uninitialized in this function plperl.c:949: warning: `ret_av' might be used uninitialized in this function indicate an actual bug --- at least, it's far from clear that the code can't try to use an uninitialized value. I trust that the authors of plperl will step up and fix it; I'm not sufficiently clear on what cases they are trying to support to want to touch it. I have just mentally walked through the code and I am fairly sure this is harmless, i.e. we should only refer to the one of these that has actually been set in any of the relevant code paths. I agree it is sloppy and will have discussions with one or two fellow perpetrators er I mean collaborators about cleaning it up. The others indicate sloppiness in the C code generated by perl's XS functionality. There's nothing we can do about them. FWIW, less obsolete versions of Perl generate fewer warnings --- the only one of these that I see on 5.8.0 and up is SPI.c:158: warning: unused variable `items' This message can actually be fixed with the addition of the following 2 lines to SPI.xs: *BOOT*: *items* = 0; /* avoid '*unused **variable*' warning */ These messages are confusing: /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used AFAICT sv_2pv_nolen should actually be used (by SPI.c) on Bruce's machine, so it's a bit strange. cheers andrew ---(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] New compile warnings
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am seeing the following compile warnings in CVS. I am using for perl: > Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: I believe these two: > plperl.c:948: warning: `ret_hv' might be used uninitialized in this function > plperl.c:949: warning: `ret_av' might be used uninitialized in this function indicate an actual bug --- at least, it's far from clear that the code can't try to use an uninitialized value. I trust that the authors of plperl will step up and fix it; I'm not sufficiently clear on what cases they are trying to support to want to touch it. The others indicate sloppiness in the C code generated by perl's XS functionality. There's nothing we can do about them. FWIW, less obsolete versions of Perl generate fewer warnings --- the only one of these that I see on 5.8.0 and up is > SPI.c:158: warning: unused variable `items' regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] New compile warnings
I am seeing the following compile warnings in CVS. I am using for perl: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: --- gmake[2]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/test/regress' gmake[1]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/test' plperl.c:948: warning: `ret_hv' might be used uninitialized in this function plperl.c:949: warning: `ret_av' might be used uninitialized in this function /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used SPI.c:25: warning: no previous prototype for `XS__elog' SPI.c:40: warning: no previous prototype for `XS__DEBUG' SPI.c:55: warning: no previous prototype for `XS__LOG' SPI.c:70: warning: no previous prototype for `XS__INFO' SPI.c:85: warning: no previous prototype for `XS__NOTICE' SPI.c:100: warning: no previous prototype for `XS__WARNING' SPI.c:115: warning: no previous prototype for `XS__ERROR' SPI.c:130: warning: no previous prototype for `XS__spi_exec_query' SPI.c:157: warning: no previous prototype for `boot_SPI' SPI.c:158: warning: unused variable `items' /usr/libdata/perl5/5.00503/i386-bsdos/CORE/patchlevel.h:41: warning: `local_patches' defined but not used ppport.h:564: warning: `sv_2pv_nolen' defined but not used -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] New compile warnings in CVS
On Wed, 2004-10-27 at 03:57, Tom Lane wrote: > No doubt this is from the PG_TRY that Neil added a couple days ago. > I think he is going to take it out again in favor of using AllocateFile, > so ignore the warnings for now (they're obviously bogus anyway). Sorry, I didn't see those compile warnings locally (using GCC 3.3). I'll send the patch for AllocateFile() to -patches shortly. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New compile warnings in CVS
Bruce Momjian <[EMAIL PROTECTED]> writes: > I just updated my CVS copy and am seeing four new warnings from > pgstat.c: > pgstat.c:2352: warning: variable `dbentry' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2360: warning: variable `havebackends' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2362: warning: variable `use_mcxt' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2363: warning: variable `mcxt_flags' might be clobbered by > `longjmp' or `vfork' No doubt this is from the PG_TRY that Neil added a couple days ago. I think he is going to take it out again in favor of using AllocateFile, so ignore the warnings for now (they're obviously bogus anyway). 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] New compile warnings in CVS
Bruce Momjian wrote: > I just updated my CVS copy and am seeing four new warnings from > pgstat.c: > > pgstat.c:2352: warning: variable `dbentry' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2360: warning: variable `havebackends' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2362: warning: variable `use_mcxt' might be clobbered by > `longjmp' or `vfork' > pgstat.c:2363: warning: variable `mcxt_flags' might be clobbered by > `longjmp' or `vfork' > > Any ideas on this? Oh this is BSD/OS 4.3 using gcc: gcc version 2.95.3 20010315 (release) -- 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 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
[HACKERS] New compile warnings in CVS
I just updated my CVS copy and am seeing four new warnings from pgstat.c: pgstat.c:2352: warning: variable `dbentry' might be clobbered by `longjmp' or `vfork' pgstat.c:2360: warning: variable `havebackends' might be clobbered by `longjmp' or `vfork' pgstat.c:2362: warning: variable `use_mcxt' might be clobbered by `longjmp' or `vfork' pgstat.c:2363: warning: variable `mcxt_flags' might be clobbered by `longjmp' or `vfork' Any ideas on this? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
