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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-bugs(at)postgresql(dot)org, "Gerhard Leykam" <gel123(at)sealsystems(dot)de>
Subject: Re: BUG #5118: start-status-insert-fatal
Date: 2009-10-15 18:37:50
Message-ID: 11547.1255631870@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> ... This would allow pg_ctl or a script to
>> connect to a port and see if it is the expected postmaster process.

> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response.

Although on second thought, any such test is worth approximately nothing
anyway. You can check that the postmaster answering the doorbell
reports the same PID that you see in $PGDATA/postmaster.pid, but that
still doesn't prove that that postmaster is using that data directory.
It could be a random coincidence of PIDs. And in the case of a start
script, the probability of random PID match to a stale lockfile is many
orders of magnitude higher than you might think; see prior discussions.

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?

[ thinks... ] Maybe we could have the postmaster generate a random
number at start and include that in both the postmaster.ports file
and its pg_ping responses. That would have a substantially lower
collision probability than PID, if the number generation process
were well designed; and it wouldn't risk exposing anything sensitive
in the ping response.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2009-10-15 18:46:41 Re: BUG #5118: start-status-insert-fatal
Previous Message Richard Neill 2009-10-15 18:35:31 Re: Postgresql 8.4.1 segfault, backtrace