Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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