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

On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> 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.)

Well, then Tom's idea of using a random number seems pretty solid no
matter how you slice it. Maybe a UUID.

...Robert