Tom Lane wrote:
> Is that actually the cause of the original bug report, or is there
> another issue yet to solve?
I still don't know what caused syslogger to die in the first place, this
bug only affects its respawning. It might not be a PostgreSQL issue at
all, but we'll see.
--
Heikki Linna
Heikki Linnakangas writes:
> 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.
Ah, thanks Windows :-(
> ! if (fd != -1)
> ! {
> !
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,
Heikki Linnakangas 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.
> Th
2010/4/1 Heikki Linnakangas :
> 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.
Wow. Looking at the code around NULL_DEV, that actually looks like a
merge mistake from the old windows br
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
