Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have generated the following patch that moves postmaster.pid into the
> configuration directory. pg_ctl only knows about the configuration
> directory because it can't read postgresql.conf, so it seems that is the
> right place to move it.
Unfortunately, that is *absolutely* unsafe. If we do that it will break
the safety property that the lock file is meant to enforce in the first
place, namely only one postmaster running in a given data directory.
It's not too hard to imagine people getting burnt by that, either:
initdb, create new config files in another directory, forget to remove
the original postgresql.conf in the data directory, and you have every
ingredient needed for disaster. Just start two postmasters with both
direct and indirect -D arguments, and kaboom.
> This patch does
> require that the postgres unix user have write permission in the
> configuration directory to create the pid file on startup.
That assumption is unacceptable, too. One of the prime reasons for
having config files somewhere else is that the somewhere else can be
read-only, thus reducing your exposure in case of a security breach.
(Otherwise, we could possibly fix this by generating a second
postmaster.pid in the config directory.)
I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf, or revert the
separate-config-file-location patch.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
