Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session |
Дата | |
Msg-id | 201009101245.o8ACjkD21094@momjian.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [BUGS] BUG #5305: Postgres service stops when closing
Windows session
|
Список | pgsql-hackers |
Magnus Hagander wrote: > > I think we have clear enough evidence that 128 on Win32 means > > no-such-child and we can be sure the child never got started on that > > platform. > > We have evidence that 128 occurs in this case. I don't think we have > evidence that there is no other case when this can happen, and we need > to investigate that some further to be *sure*. > > We can safely say that *we* never do exit(128). What if a third party > library does it? Or the operating system itself? For the OS we can > check it, but do we care about third party libraries? Good question. Unix wait() splits apart the return code so you can tell which part is the process exit code and which part is extra: WEXITSTATUS(status) If WIFEXITED(status) is true, evaluates to the low-order 8 bits of the argumentpassed to _exit(2) or exit(3) by the child. but we don't have that split on Win32 so you are right that anything could return 128 from the process. Of course, it could also return exit(0) too, but would hope that nothing does that as an error return. I am not sure how clear it is on Win32 that 128 is a special return code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: