From the users point of view, this could be a Windows or AV issue, but just stops Postgres service, does not affect or interfire on Windows stability or AV stability, instead it affect your product. So if you can improve the stability of the service (and data integrity at the most) it could be a benefic for all.
I've found the same behavior on Postgres service when clossing MSTSC session without any AV installed, and after some months of Postgres crashes, administrators installed Kaspersky for Servers AV, and crashes are still there.
Cristian.
2010/8/23 Tom Lane
<tgl@sss.pgh.pa.us>>> 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.
> It may well be, but we can at least attempt to mitigate it, no?
I'm not excited about a "mitigation" approach that introduces new
data-loss hazards of its very own. That doesn't meet the Less Evil
standard in my eyes.
[ thinks for a bit... ] Although maybe it'd be all right to piggyback
on the dead-man-switch code that already exists in pmsignal.c. If the
child process hasn't got as far as doing MarkPostmasterChildActive,
then in principle it should be okay to assume it hasn't touched shared
memory. This really is independent of what exit code it returned.
regards, tom lane
