Re: [HACKERS] Another crack at doing a Win32 build under MINGW
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] Another crack at doing a Win32 build under MINGW |
Дата | |
Msg-id | 4875.24.211.141.25.1078495856.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another crack at doing a Win32 build under MINGW ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: [HACKERS] Another crack at doing a Win32
|
Список | pgsql-hackers-win32 |
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
В списке pgsql-hackers-win32 по дате отправления: