Re: How to shoot yourself in the foot: kill -9 postmaster
| От | Tom Lane |
|---|---|
| Тема | Re: How to shoot yourself in the foot: kill -9 postmaster |
| Дата | |
| Msg-id | 6920.983906694@sss.pgh.pa.us обсуждение |
| Ответ на | Re: How to shoot yourself in the foot: kill -9 postmaster (Alfred Perlstein <bright@wintelcom.net>) |
| Ответы |
Re: How to shoot yourself in the foot: kill -9 postmaster
|
| Список | pgsql-hackers |
Alfred Perlstein <bright@wintelcom.net> writes:
> * Tom Lane <tgl@sss.pgh.pa.us> [010306 11:03] wrote:
>> I notice that our BeOS and QNX emulations of shmctl() don't support
>> IPC_STAT, but that could be dealt with, at least to the extent of
>> stubbing it out.
> Well since we already have spinlocks, I can't see why we can't
> keep the refcount and spinlock in a special place in the shm
> for all cases?
No, we mustn't go there. If the kernel isn't keeping the refcount
then it's worse than useless: as soon as some process crashes without
decrementing its refcount, you have a condition that you can't recover
from without reboot.
What I'm currently imagining is that the stub implementations will just
return a failure code for IPC_STAT, and the outer code will in turn fail
with a message along the lines of "It looks like there's a pre-existing
shmem block (id XXX) still in use. If you're sure there are no old
backends still running, remove the shmem block with ipcrm(1), or just
delete $PGDATA/postmaster.pid." I dunno what shmem management tools
exist on BeOS/QNX, but deleting the lockfile will definitely suppress
the startup interlock ;-).
> Yes, if possible a more meaningfull error message and pointer to
> some docco would be nice
Is the above good enough?
regards, tom lane
В списке pgsql-hackers по дате отправления: