"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> "Gerhard Leykam" <gel123@sealsystems.de> wrote:
>> I am using a start script to set up my PostgreSQL database: it runs
>> initdb, if not done yet, starts the instance with pg_ctl start and
>> checks everything is fine by pg_ctl status.
>>
>> If there is another PostgreSQL database on the same machine
>> listening to the same port, postmaster comes up, pg_ctl status says
>> everthings fine, but postmaster falls down with appropriate message
>> in postgres.log.
> This is definitely not a PostgreSQL bug.
Well, it's arguably a start-script bug, but I think his point is that
it's hard to fix it without any additional support from PG.
While mulling that it occurred to me that some additional output from
the postmaster would help to solve another thing that's an acknowledged
shortcoming of pg_ctl, namely that it can't parse postgresql.conf to
find out where the postmaster's communication socket is; cf
http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php
and other older complaints.
We could redefine things so that it doesn't need to do that (and also
doesn't need to try to intuit the postmaster's port number, which it
does do now, but not terribly well). Suppose that after the postmaster
is fully up, it writes a file $PGDATA/postmaster.ports, with contents
along the lines of
5432
/tmp/.s.PGSQL.5432
ie, IP port number and full socket location (the latter missing on
Windows of course). Then pg_ctl only needs to know $PGDATA, and it
can get the socket address without any guessing or hard work.
(Alternatively we could add this info to postmaster.pid, but a separate
file seems like a better idea, if only because the contents of the pid
file are subject to change that pg_ctl shouldn't have to deal with.)
I am not convinced that this solves the OP's complaint 100%. The
failure case that remains is that if the postmaster crashes without
deleting this file, then pg_ctl could still be fooled by a competing
postmaster that's taken the same port number. I don't know that there's
any good way around that one, though. The main thing it does do is
remove the pressure to add a lot of code to pg_ctl to try to read
postgresql.conf.
regards, tom lane
