Re: fork/exec patch: pre-CreateProcess finalization

Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> Tom Lane:
>> Per Jan's comment, there is no need to mess with the existing
>> datastructure. I'd think more of *copying* the dllist into some array
>> in shared memory. This is code that would only need to exist in the
>> Windows port.

> Also, let's get back to why we want this: to handle processCancelRequest in
> the Win32 case. If this array is in Windows only, then we'll obviously need
> two implementations of the processCancelRequest logic.

[ shrug... ] If that's the only redundant code we end up with in this
port, we'll have done pretty durn well.

What it comes down to is I don't want the postmaster to be keeping its
own state in shared memory --- that is, the array must be write-only
memory as far as the postmaster is concerned. If we eliminate the
postmaster's private DLList of backends, then the postmaster becomes
that much more vulnerable to corruption from a backend bug that leads to
trashing shared memory. To take just one example: backend A goes nuts,
zeroes the whole shmem segment, and then dumps core. How is the
postmaster going to kill the other backends so that it can begin the
recovery process? If there's no record of their PIDs left anywhere,
it's got a problem. The postmaster *needs* its own copy of that DLList.

You might object that backend bugs could clobber the array and thus
interfere with cancel request processing, but that's not nearly as
critical a function.

regards, tom lane