"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > "Gerhard Leykam" <gel...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
