On Mon, Aug 23, 2010 at 11:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Mon, Aug 23, 2010 at 17:09, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
