Thread: 7.3 failure on platypus
Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about 12 days ago with the following: ccache gcc -O3 -pipe -pipe -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I. -I../../../src/include-I/usr/local/include -DFRONTEND -DSYSCONFDIR='"/home/buildfarm/buildfarm/REL7_3_STABLE/inst/etc/postgresql"' -c -o fe-misc.o fe-misc.c fe-auth.c: In function `pg_local_sendauth': fe-auth.c:466: error: conflicting types for 'cmsgmem' fe-auth.c:459: error: previous declaration of 'cmsgmem' was here fe-auth.c:469: error: redefinition of 'cmsg' fe-auth.c:462: error: previous definition of 'cmsg' was here fe-auth.c:462: warning: unused variable `cmsg' gmake[3]: *** [fe-auth.o] Error 1 gmake[3]: *** Waiting for unfinished jobs.... gmake[3]: Leaving directory `/home/buildfarm/buildfarm/REL7_3_STABLE/pgsql.62497/src/interfaces/libpq' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/buildfarm/buildfarm/REL7_3_STABLE/pgsql.62497/src/interfaces' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/buildfarm/buildfarm/REL7_3_STABLE/pgsql.62497/src' gmake: *** [all] Error 2 The machine was having some issues during that time and we did recently upgrade to FreeBSD 6.0, but all the other branches are clean. Any ideas? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes: > Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about 12 > days ago with the following: > fe-auth.c: In function `pg_local_sendauth': > fe-auth.c:466: error: conflicting types for 'cmsgmem' > fe-auth.c:459: error: previous declaration of 'cmsgmem' was here Yeah, all of the freebsd 6 buildfarm machines say that :-( ... the fbsd6 system headers contain some incompatible changes, evidently. It looks like we dealt with this in 7.4 but didn't risk back-patching. The PG 7.3 branch is definitely showing its age. I'm not sure how interesting it is to keep updating it for newer platforms; is anyone very likely to run 7.3 on a new machine, rather than some later PG? (Note: while I have a personal need to keep supporting 7.3 on RHEL3, this requirement does not extend to any later platforms; so I don't personally care very much about back-porting fixes like this. Obviously my opinion is biased by what Red Hat cares about.) regards, tom lane
On Mon, Dec 12, 2005 at 06:44:23PM -0500, Tom Lane wrote: > The PG 7.3 branch is definitely showing its age. I'm not sure how > interesting it is to keep updating it for newer platforms; is anyone > very likely to run 7.3 on a new machine, rather than some later PG? Probably no one... I'll just gank it from playtypus's config. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Tom Lane said: > "Jim C. Nasby" <jnasby@pervasive.com> writes: >> Platypus (http://lnk.nu/pgbuildfarm.org/6yt.pl) started failing about >> 12 days ago with the following: >> fe-auth.c: In function `pg_local_sendauth': >> fe-auth.c:466: error: conflicting types for 'cmsgmem' >> fe-auth.c:459: error: previous declaration of 'cmsgmem' was here > > Yeah, all of the freebsd 6 buildfarm machines say that :-( ... the > fbsd6 system headers contain some incompatible changes, evidently. It > looks like we dealt with this in 7.4 but didn't risk back-patching. > > The PG 7.3 branch is definitely showing its age. I'm not sure how > interesting it is to keep updating it for newer platforms; is anyone > very likely to run 7.3 on a new machine, rather than some later PG? > > (Note: while I have a personal need to keep supporting 7.3 on RHEL3, > this requirement does not extend to any later platforms; so I don't > personally care very much about back-porting fixes like this. > Obviously my opinion is biased by what Red Hat cares about.) > I don't care that much if 7.3 fails to build on fbsd 6. The flipside is that the fix for this particular problem appears to be very simple and very low risk, unless I'm going blind. cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> I don't care that much if 7.3 fails to build on fbsd 6. The flipside is that
> the fix for this particular problem appears to be very simple and very low
> risk, unless I'm going blind.
Possibly --- if you've gone to the trouble of identifying the relevant
patch, we might as well apply it. Send it over.
regards, tom lane
Tom Lane said: > "Andrew Dunstan" <andrew@dunslane.net> writes: >> I don't care that much if 7.3 fails to build on fbsd 6. The flipside >> is that the fix for this particular problem appears to be very simple >> and very low risk, unless I'm going blind. > > Possibly --- if you've gone to the trouble of identifying the relevant > patch, we might as well apply it. Send it over. > away from my workstation, but it looks to me like the HAVE_STRUCT_SOCKCRED branch is completely redundant in that function, since the structures in question are only referred to in a HAVE_CMSGCRED branch. I think I'd just delete lines 464-470 in http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71 Jim, can you test that? (I don't have a fbsd box either). cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes: > I think I'd just delete lines 464-470 in > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71 I confirmed that this is the patch appearing in 7.4 (fe-auth.c rev 1.84), so went ahead and applied it to 7.3. regards, tom lane
On Mon, Dec 12, 2005 at 10:39:47PM -0500, Tom Lane wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > > I think I'd just delete lines 464-470 in > > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71 > > I confirmed that this is the patch appearing in 7.4 (fe-auth.c rev > 1.84), so went ahead and applied it to 7.3. Seems to have worked... but now there's another problem... creating template1 database in data/base/1... IpcSemaphoreCreate: semget(key=3, num=17, 03600) failed: No space left on device The error talks about SEMMNI and SEMMNS, but both look ok... kern.ipc.semmns: 100 kern.ipc.semmni: 10 buildfarm@fritz.1[0:51]~/buildfarm/source:141>ipcs Message Queues: T ID KEY MODE OWNER GROUP Shared Memory: T ID KEY MODE OWNER GROUP m 65536 5432001 --rw------- pgsql pgsql Semaphores: T ID KEY MODE OWNER GROUP s 65536 5432001 --rw------- pgsql pgsql s 65537 5432002 --rw------- pgsql pgsql s 65538 5432003 --rw------- pgsql pgsql All the other branches are working fine as well, so I'm wondering if this is some other issue... This first appeared 26 days ago: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2005-11-16%2007:35:00 But the only file changed there is documentation... that's also before we upgraded the machine, so it doesn't appear to be related to that either. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> The error talks about SEMMNI and SEMMNS, but both look ok...
> kern.ipc.semmns: 100
That's not enough to run two postmasters ...
regards, tom lane
On Tue, Dec 13, 2005 at 02:03:13AM -0500, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > The error talks about SEMMNI and SEMMNS, but both look ok... > > > kern.ipc.semmns: 100 > > That's not enough to run two postmasters ... Odd that it works for other branches... That's a boot-time only parameter; you think 200 would be enough? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > On Mon, Dec 12, 2005 at 10:39:47PM -0500, Tom Lane wrote: > >>"Andrew Dunstan" <andrew@dunslane.net> writes: >> >>>I think I'd just delete lines 464-470 in >>>http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71 >> >>I confirmed that this is the patch appearing in 7.4 (fe-auth.c rev >>1.84), so went ahead and applied it to 7.3. > > > Seems to have worked... but now there's another problem... > I don't know if this is yet another one, but happened to rebuild 7.3.12 on a FreeBSD 6.0 box today and I notice that it fails float8 regression test (geometry does too but that is marked as ignorable). This is with the informal patch applied to fe-auth.c. (see attached regression.diff). regards Mark *** ./expected/float8-small-is-zero.out Wed Oct 23 09:01:15 2002 --- ./results/float8.out Thu Dec 15 12:17:34 2005 *************** *** 274,280 **** --- 274,282 ---- INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Input '-10e400' is out of range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400'); + ERROR: Input '10e-400' is out of range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400'); + ERROR: Input '-10e-400' is out of range for float8 -- maintain external table consistency across platforms -- delete all values and reinsert well-behaved ones DELETE FROM FLOAT8_TBL; ====================================================================== *** ./expected/geometry-positive-zeros-bsd.out Wed Sep 13 09:07:16 2000 --- ./results/geometry.out Thu Dec 15 12:18:24 2005 *************** *** 114,120 **** | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10) | [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0) | [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 114,120 ---- | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10) | [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0) | [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) *************** *** 224,233 **** twentyfour | rotation ------------+----------------------------- | (0,0),(0,0) ! | (0,0),(-20,-20) ! | (0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) --- 224,233 ---- twentyfour | rotation ------------+----------------------------- | (0,0),(0,0) ! | (-0,0),(-20,-20) ! | (-0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,-0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) *************** *** 254,264 **** WHERE (p.f1 <-> point '(0,0)') >= 1; twenty | rotation --------+----------------------------------------------------------------------------------- ! | (0,0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) --- 254,264 ---- WHERE (p.f1 <-> point '(0,0)') >= 1; twenty | rotation --------+----------------------------------------------------------------------------------- ! | (0,-0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,-0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) *************** *** 266,272 **** | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! | (0,0.0828402366863905),(-0.201183431952663,0) | (-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953) | (-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201) | (-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586) --- 266,272 ---- | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! | (-0,0.0828402366863905),(-0.201183431952663,0) | (-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953) | (-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201) | (-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586) ======================================================================
Mark Kirkwood <markir@paradise.net.nz> writes:
> I don't know if this is yet another one, but happened to rebuild 7.3.12
> on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> test (geometry does too but that is marked as ignorable).
7.3 is too old to know that freebsd beyond 4.x doesn't suffer from the
float8-small-is-zero syndrome.
This is only a one-line change in resultmap, so I patched it (please
check that it works now!). In general, though, this is just another
data point in support of my previous opinion that trying to keep old
branches up-to-date with platforms that are moving targets isn't a very
sane goal. Why would someone be using an old database on a current
kernel?
regards, tom lane
Tom Lane wrote: > Mark Kirkwood <markir@paradise.net.nz> writes: > >>I don't know if this is yet another one, but happened to rebuild 7.3.12 >>on a FreeBSD 6.0 box today and I notice that it fails float8 regression >>test (geometry does too but that is marked as ignorable). > > > 7.3 is too old to know that freebsd beyond 4.x doesn't suffer from the > float8-small-is-zero syndrome. > > This is only a one-line change in resultmap, so I patched it (please > check that it works now!). Will do (soon as it appears in anoncvs). > In general, though, this is just another > data point in support of my previous opinion that trying to keep old > branches up-to-date with platforms that are moving targets isn't a very > sane goal. Why would someone be using an old database on a current > kernel? > Sure is! cheers Mark
Mark Kirkwood wrote: > Tom Lane wrote: > >> Mark Kirkwood <markir@paradise.net.nz> writes: >> >>> I don't know if this is yet another one, but happened to rebuild >>> 7.3.12 on a FreeBSD 6.0 box today and I notice that it fails float8 >>> regression test (geometry does too but that is marked as ignorable). >> >> >> >> 7.3 is too old to know that freebsd beyond 4.x doesn't suffer from the >> float8-small-is-zero syndrome. >> >> This is only a one-line change in resultmap, so I patched it (please >> check that it works now!). Post patch it passes float8. For completeness this was Pg 7.3.12 on FreeBSD 6.0-RELEASE x86).
On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote: > Mark Kirkwood <markir@paradise.net.nz> writes: > > I don't know if this is yet another one, but happened to rebuild 7.3.12 > > on a FreeBSD 6.0 box today and I notice that it fails float8 regression > > test (geometry does too but that is marked as ignorable). > > 7.3 is too old to know that freebsd beyond 4.x doesn't suffer from the > float8-small-is-zero syndrome. > > This is only a one-line change in resultmap, so I patched it (please > check that it works now!). In general, though, this is just another > data point in support of my previous opinion that trying to keep old > branches up-to-date with platforms that are moving targets isn't a very > sane goal. Why would someone be using an old database on a current > kernel? Well, you could make the argument that switching OSes is a lot less involved than switching PostgreSQL versions, especially since a dump/reload isn't required... Is the work involved here actually applying the patch or is it porting an existing patch to older versions? The later is something that newbie hackers could do (most of the time), which would be both a good way to get feet wet and reduce the load on folks such as yourself. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Thursday 15 December 2005 12:02, Jim C. Nasby wrote:
> On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote:
> > Mark Kirkwood <markir@paradise.net.nz> writes:
> > > I don't know if this is yet another one, but happened to rebuild 7.3.12
> > > on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> > > test (geometry does too but that is marked as ignorable).
> >
> > 7.3 is too old to know that freebsd beyond 4.x doesn't suffer from the
> > float8-small-is-zero syndrome.
> >
> > This is only a one-line change in resultmap, so I patched it (please
> > check that it works now!). In general, though, this is just another
> > data point in support of my previous opinion that trying to keep old
> > branches up-to-date with platforms that are moving targets isn't a very
> > sane goal. Why would someone be using an old database on a current
> > kernel?
>
> Well, you could make the argument that switching OSes is a lot less
> involved than switching PostgreSQL versions, especially since a
> dump/reload isn't required...
>
How exactly do you switch the OS your database is running on without a
dump/reload?
The one thing I am wondering is would people accept older OS's into the
buildfarm? I think there are still a lot of servers running red hat 7.3,
that might be an example of an old OS that we could put into the buildfarm to
test for the 7.3.x or 7.4.x series.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: >The one thing I am wondering is would people accept older OS's into the >buildfarm? I think there are still a lot of servers running red hat 7.3, >that might be an example of an old OS that we could put into the buildfarm to >test for the 7.3.x or 7.4.x series. > > > "people" = me ;-) I have no objection to old operating systems being included. cheers andrew
Robert Treat <xzilla@users.sourceforge.net> writes:
> The one thing I am wondering is would people accept older OS's into the
> buildfarm? I think there are still a lot of servers running red hat 7.3,
> that might be an example of an old OS that we could put into the buildfarm to
> test for the 7.3.x or 7.4.x series.
Sure. I don't see any reason the newer branches shouldn't be expected
to pass on such machines, either.
regards, tom lane
On Thu, Dec 15, 2005 at 01:16:09PM -0500, Robert Treat wrote: > > Well, you could make the argument that switching OSes is a lot less > > involved than switching PostgreSQL versions, especially since a > > dump/reload isn't required... > > > > How exactly do you switch the OS your database is running on without a > dump/reload? err, sorry. s/switch/upgrade/ -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461