Re: Syslogger tries to write to /dev/null on Windows

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> A customer is facing a problem on PostgreSQL 8.3.10 on Windows where the
> syslogger process dies mysteriously every few hours under load. I
> haven't yet figured out why, but when postmaster tries to respawn
> syslogger, it doesn't start up but dies immediately.

> The reason the relaunch fails is that in SysLoggerMain we have this:
>> /*
>> * If we restarted, our stderr is already redirected into our own input
>> * pipe. This is of course pretty useless, not to mention that it
>> * interferes with detecting pipe EOF. Point stderr to /dev/null. This
>> * assumes that all interesting messages generated in the syslogger will
>> * come through elog.c and will be sent to write_syslogger_file.
>> */
>> if (redirection_done)
>> {
>> int fd = open(NULL_DEV, O_WRONLY, 0);
>>
>> /*
>> * The closes might look redundant, but they are not: we want to be
>> * darn sure the pipe gets closed even if the open failed. We can
>> * survive running with stderr pointing nowhere, but we can't afford
>> * to have extra pipe input descriptors hanging around.
>> */
>> close(fileno(stdout));
>> close(fileno(stderr));
>> dup2(fd, fileno(stdout));
>> dup2(fd, fileno(stderr));
>> close(fd);
>> }

> NULL_DEV is defined in c.h as "/dev/null", which doesn't work on
> windows. We have a port-specific #define DEVNULL which does work, we
> should be using that.

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.

regards, tom lane