'k, an excerpt from a thread on the freebsd lists ... I'm not sure how to
answer:
----
On Sun, Apr 02, 2006 at 05:24:10PM -0300, Marc G. Fournier wrote:
On Sun, 2 Apr 2006, Kris Kennaway wrote:
>>Right, but why are they doing it *consistently* in FreeBSD 6.x, when
they
>>never did it in FreeBSD 4.x? I have postmaster processes running on
the
>>FreeBSD box as far back as November 27th, 2005 ... and have *never*
>>experienced this problem ... so it isn't PostgreSQL that has changed,
>>something in FreeBSD has changed :(
>
>You'll need to do some debugging to find out which of the two causes
>of EINVAL are true here (or some undocumented cause).
'k, right now, the checks in PostgreSQL are just seeing if the result of
semctl < 0 ... i see from the man page what 'two values' of EINVAL you
are
referring to ... but, if they both return the same ERRNO, how do I
determine which of the two is the cause of the problem? :(
Evaluate context: what other semaphore operations have been performed
previously?
Kris
------
is there any easy way to answer this? I'm getting the Invalid Argument
error for SETVAL and IPC_RMID ...
On Sun, 2 Apr 2006, Marc G. Fournier wrote:
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster