Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
От | Cristian Bittel |
---|---|
Тема | Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session |
Дата | |
Msg-id | AANLkTimUiDEVrNg0AdiJ=x2R9Rrob+ju4+K7T5VGOGuB@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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/>
В списке pgsql-hackers по дате отправления: