On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Aug 23, 2010 at 17:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
I'm confused. That seems like it would be LESS safe than the proposed
approach of taking a mutex just before mapping shared memory. There
is some finite amount of code that executes after shared memory is
mapped and before MarkPostmasterChildActive executes; the advantage of
the mutex is that it can be taken BEFORE shared memory is mapped. On
the other hand, if you think it's safe enough, it would certainly be
nice to use an existing mechanism rather than inventing something
totally new.
I agree that the exit code is irrelevant.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
