I wrote:
> I was thinking at the time, and still think, it is reasonable to treat
> EPERM as being a safe rather than unsafe case.
I remembered why we were rejecting that case originally: it protects us
against blowing away a Unix socket file belonging to a postmaster that's
running under someone
Tom Lane <[EMAIL PROTECTED]> writes:
> We need to be able to write in the whole directory, not just the
> lockfile. But actually the point I am making above is in your favor:
> after adding a check on ownership, it would be a matter of your
> protection wishes what the directory protections need
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I am strongly tempted to add a direct check in checkDataDir() that the
>> data directory actually does belong to our own uid, just for paranoia's
>> sake. Someone might decide that they could relax the permission chec
Tom Lane wrote:
>But I evidently didn't
>read the code quite carefully enough: as CreateLockFile() is written,
>it considers an EPERM error from kill() to be reason to treat the
>lockfile as valid.
>
>
I thought that was part of what you were going to address. There can
hardly be an objection
Tom Lane <[EMAIL PROTECTED]> writes:
> I am strongly tempted to add a direct check in checkDataDir() that the
> data directory actually does belong to our own uid, just for paranoia's
> sake. Someone might decide that they could relax the permission check
> ("hey, why not let the dbadmin group ha
Last fall I proposed a minor tweak to solve the problem of Postgres
not restarting after a system reboot, in cases where it looked at the
old lockfile and thought the old postmaster was still alive:
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00935.php
However it turns out the bug is s
