Thread: 7.3 failure on platypus

7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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


Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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


Re: 7.3 failure on platypus

From
"Andrew Dunstan"
Date:
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




Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
"Andrew Dunstan"
Date:
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





Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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


Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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


Re: 7.3 failure on platypus

From
Mark Kirkwood
Date:
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)

======================================================================


Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
Mark Kirkwood
Date:
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


Re: 7.3 failure on platypus

From
Mark Kirkwood
Date:
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).



Re: 7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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


Re: 7.3 failure on platypus

From
Robert Treat
Date:
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


Re: 7.3 failure on platypus

From
Andrew Dunstan
Date:

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


Re: 7.3 failure on platypus

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


Re: 7.3 failure on platypus

From
"Jim C. Nasby"
Date:
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