>>> On Fri, Aug 31, 2007 at 3:10 PM, in message <1068(dot)1188591013(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Well, that's not due to a bug in PostgreSQL. We're using a buggy LDAP
>> implementation (not my call) which can crash things. The machine totally
>> locked up after logging distress messages from that daemon, and they cycled
>> power to get out of it.
>
> Hmm. Do I correctly grasp the picture that you've got several Postgres
> installations on the machine and they're all booted by startup scripts?
Several is an understatement. This is the machine where we're running one
PostgreSQL instance per county in "warm standby" mode -- not to actually use
in recovery, but only to confirm that the backups are flowing back and
applying cleanly. So, 72 instances, on ports 5401 to 5472.
> In this situation, it's actually not a bad idea to run each one under a
> separate userid.
OK, I'll see about getting that set up.
> (Some people prefer to fix this by having a startup script that forcibly
> removes all the lockfiles before launching the postmasters. I think
> that's kinda risky, although if it's done in a separate script that
> you'd have no reason to run by hand, it's probably OK.
I don't like that idea much. I'd rather add 72 new OS users.
> BTW, I would imagine that some scenario like this preceded the problem
> that you actually reported, since had all the postmasters started
> successfully, they'd all have written correct lockfiles.
Quite likely. Most of the action happened before I arrived for the day.
Thanks.
-Kevin