> > 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.
//Magnus