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 | 6810.983905024@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: >> Are there any portability problems with relying on shm_nattch to be >> available? If not, I like this a lot... > Well it's available on FreeBSD and Solaris, I'm sure Redhat has > some deamon that resets the value to 0 periodically just for kicks > so it might not be viable... :) 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. This does raise the question of what to do if shmctl(IPC_STAT) fails for a reason other than EINVAL. I think the conservative thing to do is refuse to start up. On EPERM, for example, it's possible that there is a postmaster running in your PGDATA but with a different userid. > Seriously, there's some dispute on the type that 'shm_nattch' is, > under Solaris it's "shmatt_t" (unsigned long afaik), under FreeBSD > it's 'short' (i should fix this. :)). > But since you're really only testing for 0'ness then it shouldn't > really be a problem. We need not copy the value anywhere, so as long as the struct is correctly declared in the system header files I don't think it matters what the field type is ... regards, tom lane
В списке pgsql-hackers по дате отправления: