Robert Haas <robertmh...@gmail.com> writes: > After some discussion with Magnus, I think what is going on here is > that the postmaster kicks off a new child process, which terminates > before it actually starts running our code, either in OS-supplied code > or some sort of "filter" like anti-spam or anti-virus software. It's > presumably NOT dying in our code because - at least AFAICS - we don't > exit(128) anywhere.
IIRC, in POSIX-compliant shells there's a specific convention about what exit(128) means, and it's something that could result from exec() failure. It might be too much of a stretch to suppose that Windows is following that, but if it is, that would square with your idea that this is happening during child process startup. > One way we could possibly improve the situation > is to not treat this as a child crash - that is, don't do a > crash-and-restart cycle; just treat that backend as having done > elog(FATAL). That seems to me like a great idea for decreasing reliability, not increasing it. If you mistakenly classify a child death as "not a crash" then you're really seriously hosed; the best outcome you can hope for is that the database freezes up without doing any major damage to itself. Furthermore, even if it is an early exit and you can afford to ignore it, the client side is still going to see a dropped connection and tell the user that the server crashed, and we're still going to get bug reports about that. I would be inclined to write this off as Windows randomness that's unfixable on our end. We could recommend that people take a closer look at what AV software they have installed and maybe try some other one. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers