From the users point of view, this could be a Windows or AV issue, but just stops Postgres service, does not affect or
interfireon Windows stability or AV stability, instead it affect your product. So if you can improve the stability of
theservice (and data integrity at the most) it could be a benefic for all.<br /><br />I've found the same behavior on
Postgresservice when clossing MSTSC session without any AV installed, and after some months of Postgres crashes,
administratorsinstalled Kaspersky for Servers AV, and crashes are still there.<br /><br /> Cristian.<br /><br /><br
/><divclass="gmail_quote">2010/8/23 Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span><br/><blockquote class="gmail_quote" style="margin: 0pt
0pt0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Magnus Hagander <<a
href="mailto:magnus@hagander.net">magnus@hagander.net</a>>writes:<br /> > On Mon, Aug 23, 2010 at 17:09, Tom Lane
<<ahref="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /></div><div class="im">>> I would be
inclinedto write this off as Windows randomness that's<br /> >> unfixable on our end. We could recommend that
peopletake a closer<br /> >> look at what AV software they have installed and maybe try some other<br /> >>
one.<br/><br /> > It may well be, but we can at least attempt to mitigate it, no?<br /><br /></div>I'm not excited
abouta "mitigation" approach that introduces new<br /> data-loss hazards of its very own. That doesn't meet the Less
Evil<br/> standard in my eyes.<br /><br /> [ thinks for a bit... ] Although maybe it'd be all right to piggyback<br />
onthe dead-man-switch code that already exists in pmsignal.c. If the<br /> child process hasn't got as far as doing
MarkPostmasterChildActive,<br/> then in principle it should be okay to assume it hasn't touched shared<br /> memory.
Thisreally is independent of what exit code it returned.<br /><br /> regards, tom lane<br
/></blockquote></div><br/>