Magnus Hagander said:
>> > I've seen both these messages after each other when -i is not
>> > specified. Been meaning to adress the issue of it not failing
>> > gracefully without -i on win32.
>> >
>> > Anyway. It seems the postmaster goes down while a child process is
>> > still going up (stats collector, I guess) or something along that
>> > line. This way the child can't attach to shared memory, and
>> there you
>> > go.
>> >
>> > If you add PID information to the log, you will notice that the
>> > messages are from two different processes.
>> >
>>
>> Is there a case for forcing -i and ignoring the GUC setting
>> on Windows? Since we can't do Unix domain sockets there it
>> would seem to make sense.
>
> Yeah, that could be done. I was more into doing a generic fix that
> would fail gracefully in any case when the server is not listening on
> anything (no Unix, no TCPIP) and error out then.
>
> Are there any other platforms which don't have unix sockets? If not,
> then that thought is not valid, and we shuold just force it on win32.
> If not, how do they handle starting of the postmaster without -i today?
> And do we want the same behaviour there?
>
> Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
> way we don't suddenly open up to external connections without the user
> asking for it.
>
Hmm. That also raises the question of what we should do if virtual_host is
set.
[thinks some more ...]
cheers
andrew