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
"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
Import Notes
Reply to msg id not found: 3903.24.211.165.134.1134436968.squirrel@www.dunslane.net
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 hereYeah, 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
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.71I 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.71I 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
Attachments:
regression.diffstext/plain; name=regression.diffsDownload
*** ./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