Tom Lane wrote:
> Allan Engelhardt <allane@cybaea.com> writes:
>
>>If my (RH 7.1) system crashes PostgreSQL does not restart automatically
>>because the shared memory segment identifier and the .pid file remains,
>>
>
> That's kinda hard to believe; how would a shared memory segment survive
> a system crash?
I don't think they can. Some options:
(1) PostgreSQL keeps a reference to it somewhere and can get confused...
(2) Red Hat's script for starting PostgreSQL at boot time, which (a)
ran, (b) failed, and [Arrrgh! I *must* fix that stupid script ;-P] (c)
directs all pg_ctl output (out+err) to /dev/null, somehow fubared the
system.
> Darn, I thought we had fixed that class of problems. Would you try
> tracing through SharedMemoryIsInUse() to figure out why it thinks that?
> It could be that there's some platform-specific variation of shmctl()
> behavior that we need to cater for.
Uhm, my system doesn't crash *that* often... :-)
Seriously: I tried to reproduce using SysRq+S, SysRq+B and couldn't. I
think I have seen enough fsck for one night, so I might give it a rest...
>>What is the "proper" way of ensuring (as far as possible) that
>>PostgreSQL starts automatically after a crash? Is it sufficient (and
>>safe) to include a 'rm -f $PGDATA/postmaster.pid' in the system boot
>>scripts?
>>
>
> You can do that if you want, but MHO is that this is a bug we need to
> fix.
I'll see what I can do about reproducing it...
Allan
