semaphore usage "port based"? - Mailing list pgsql-hackers

From Marc G. Fournier
Subject semaphore usage "port based"?
Date
Msg-id 20060402163504.T947@ganymede.hub.org
Whole thread Raw
Responses Re: semaphore usage "port based"?  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: semaphore usage "port based"?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I've got an odd issue that I'm not sure how to fix ... or, if fixing is 
even possible ...

I just put into place a FreeBSD 6.x server ... it has 2 jails running on 
it, and inside of each, I'm trying to run a PostgreSQL 7.4.12 server 
(OpenACS requirement, no choice there) ...

Now, on my older FreeBSD 4.x servers, I have about 17 PostgreSQL servers 
(some 7.2, some 7.4, some 8.x) ... and they all run fine, and they all run 
on port 5432 ...

Now, something in FreeBSD has changed since 4.x that, if you start up a 
second PostgreSQL server on port 5432, the first one starts to generate 
"semctl: Invalid argument" errors ...

If I move one to port 5433, both run great ...

Now, since this *did* work fine with 4.x, the FreeBSD developers have 
obviously changed something that is causing it not to work ... but, since 
'changing port' appears to fix it, I'm wondering if there is something in 
our Semaphore creation code that can be tweaked so that the semaphore side 
of things *thinks* its running on a different port, but it still responses 
to port 5432?

Or, more simply, I think ... is there somewhere in the Semaphore code that 
is using the port # as a 'seed'?

I'm trying to attack things from the FreeBSD side too, to find out what 
has changed, and how to fix it, but figured I might be able to come up 
with a quicker fix from this group ...

Thx ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_class catalog question...
Next
From: "Gustavo Tonini"
Date:
Subject: Re: Slony-I for circular replication