You are quite correct. They assume that there will be one and only one
postmaster, which may be started or stopped at runlevel switch or
manually via /etc/rc.d/init.d/postmaster stop|start|restart
Similar systems have made PIDfiles like:
/var/run/postgres/5432
Which would get around the single-postmaster limitation and allow you to
make postgres own the PID directory. Whether this has traversal-rights
issues or not, I don't know. Red Hat control starts the postmaster as an
'su' process from root, and they may do the WRITING of the PIDfile from
that account.
Tom Lane wrote:
>
> Tim Holloway <mtsinc@southeast.net> writes:
> > Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.
>
> If they did it just like that, then they broke the ability to run more
> than one postmaster on the same machine. Also, there is the question
> of what the permissions are on /var/lock. If they're tight then postgres
> can't be an ordinary unprivileged user, which is bad. If they're loose
> then anyone can come along and cause trouble by fiddling with the lock
> files.
>
> There was considerable discussion of this whole area last year in
> pg-hackers (check the thread "flock patch breaks things here" and
> related threads starting in late Aug. 1998). We were focusing mostly
> on the use of lockfiles to ensure that one didn't accidentally start
> two postmasters in the same database dir and/or with the same port
> number; but if the lockfiles contain PIDs then of course they can also
> serve as a contact point for a signal-sender.
>
> Tatsuo, if you have forgotten that discussion you may want to go back
> and re-read it.
>
> regards, tom lane
