Tom Lane wrote: > Hmm. I agree with your proposed change, but it seems to me that there > is still another mystery here: why does the mistaken open() argument > lead to a crash? Per the second comment, this code is supposed to keep > working even if the open() fails. If it fails because of that, we have > robustness problems everywhere not only on Windows --- consider ENFILE > or some such.
Hmm, good question. The open() fails and returns a return code as you would expect. But the dup2() call crashes when passed an invalid file descriptor, I just tested that with a small test program on Windows. Googling around, this seems to be because of a feature called Parameter Validation: http://msdn.microsoft.com/en-us/library/ksazx244.aspx Following the example there to set a custom Invalid Parameter Handler Routine makes dup2() not crash on an invalid file handle. We could do that in PostgreSQL, setting a handler that reports a warning in the log and continues. Or we could just be more careful when passing parameters to system functions; this is the first time we hear about this so it doesn't seem to be a very widespread issue. In this case we should do this: *** a/src/backend/postmaster/syslogger.c --- b/src/backend/postmaster/syslogger.c *************** *** 194,202 **** */ close(fileno(stdout)); close(fileno(stderr)); ! dup2(fd, fileno(stdout)); ! dup2(fd, fileno(stderr)); ! close(fd); } /* --- 194,205 ---- */ close(fileno(stdout)); close(fileno(stderr)); ! if (fd != -1) ! { ! dup2(fd, fileno(stdout)); ! dup2(fd, fileno(stderr)); ! close(fd); ! } } /* -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
