Re: How to shoot yourself in the foot: kill -9 postmaster

From: Cyril VELTER <cyril(dot)velter(at)libertysurf(dot)fr>
To: pgsql-hackers(at)postgreSQL(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Date: 2001-03-07 00:04:20
Message-ID: 00037edf885b7154_mailit@mail.cybercable.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


BeOS haven't this stat (I have a bunch of others but not this one).

If I unsterstand correctly, you want to check if there is some backend
still attached to shared mem segment of a given key ? In this case, I have an
easy solution to fake the stat, because all segment have an encoded name
containing this key, so I can count them.

cyril

>
>Alfred Perlstein <bright(at)wintelcom(dot)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
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michal Maruka 2001-03-07 00:15:49 psql missing feature
Previous Message Mathijs Brands 2001-03-06 23:46:01 Re: Re: [HACKERS] why the DB file size does not reduce when 'delete'the data in DB?