Re: BUG #5118: start-status-insert-fatal

Pedro Gimeno <pgsql-003@personal.formauri.es> wrote:
> Tom Lane wrote:
>
>> This could be addressed by having the postmaster report its $PGDATA
>> value in the pg_ping response, but I would be against that on
>> security grounds.  We don't let nonprivileged users know where
>> PGDATA is, why would we make the information available without any
>> authentication at all?
>
> Maybe a hash of it?

I'm not really clear on why it's a security issue for someone to know
the $PGDATA value, but if it is, there are some "typical" locations
for which a hash could be generated and matched against the returned
hash; so a hash of it would only be safe for those who chose
sufficiently "creative" directory paths.

On top of that, I'm not sure it's a very useful way to confirm that
you've connected to the correct instance.  We often get requests to
replace the contents of a development or test database with a dump
from a production database.  More than once, the DBA doing this has
forgotten to stop PostgreSQL before deleting the $PGDATA directory and
creating it fresh for the restore of the PITR dump. When we attempt to
start the new copy, which has the same $PGDATA, owner, and port number
as the copy still running in the deleted directory, we have similar
issues to those described in the original post.  So, personally, I
consider the data directory a less reliable test than the pid.  (We
don't have a lot of OS crash & reboot occurrences.)

-Kevin