Tom Lane <t...@sss.pgh.pa.us> wrote: > Well, it's arguably a start-script bug OK. > 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 The listen_addresses setting would need to figure in, too. http://archives.postgresql.org/pgsql-hackers/2009-10/msg00022.php Matching that stuff up could start to get a little messy, but it should be doable somehow. This seems likely to overlap the review I was soon going to do of the differences between pg_ctl behavior and what is required for LSB conformance. I'll make sure to test this behavior along with others. One of my current complaints is that pg_ctl doesn't wait until it is actually ready to receive connections before returning an indication of success. I see that I neglected that point in my recently proposed LSB conforming script, but I'm guessing that this fits with other points in the argument that if what I'm doing in the script is demonstrably better than current pg_ctl behavior, we should change pg_ctl to support it rather than scripting around it. (Not that it would be hard to add ten or twenty lines to the script to cover this....) -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
