Re: InitDB: Bad system call

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Torsten Zühlsdorff <foo(at)meisterderspiele(dot)de>
Cc: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: InitDB: Bad system call
Date: 2010-08-15 16:05:08
Message-ID: 20660.1281888308@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?ISO-8859-1?Q?Torsten_Z=FChlsdorff?= <foo(at)meisterderspiele(dot)de> writes:
> The problems are known and i already have taken care of it. As written
> at the beginning i already have two jails at the server with running
> postgresql-instances.
> Normally you have to tweak up the IPC-Params and use different user-ids
> for each postgres-user to avoid the problem with the shared memory.
> Thats why my problem is very strange. I never run into such a problem
> and i run nearly a dozen postgresqls in jails at different FreeBSDs.

Now that I'm a bit more awake, I do notice something interesting about
that stack trace: the shmctl() is being executed to see whether a shared
memory segment ID mentioned in postmaster.pid still exists. This
implies that some previous incarnation of the postmaster got as far as
writing postmaster.pid, which implies that it successfully executed
shmget() and shmat(), and then crashed later. The simplest explanation
I can think of is that it's *only* shmctl that is malfunctioning, not
the other SysV shared memory calls. Which is even weirder, and
definitely seems to move the problem into the category of kernel bug
rather than configuration mistake.

I concur with the upthread suggestion that you need to update your
FreeBSD instance.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Torsten Zühlsdorff 2010-08-15 16:07:04 Re: InitDB: Bad system call
Previous Message Joe Conway 2010-08-15 15:57:11 Re: return setof : alternatives to holder table