Re: How to shoot yourself in the foot: kill -9 postmaster
От | Alfred Perlstein |
---|---|
Тема | Re: How to shoot yourself in the foot: kill -9 postmaster |
Дата | |
Msg-id | 20010306113432.Q8663@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: How to shoot yourself in the foot: kill -9 postmaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [010306 11:30] wrote: > 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. Not if the postmaster outputs the following: > 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? Sure. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
В списке pgsql-hackers по дате отправления: