Pedro Gimeno <pgsql-003(at)personal(dot)formauri(dot)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