Tom Lane wrote:
> 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
Ok. Well, I can appreciate things from that point of view.
> 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.
Actually, if I was going to argue anything, I'd say that if a backend goes
nuts and zeroes the whole shmem segment you've probably some bigger things
to worry about (Aside: Would postgres actually recover from such an
occurence? BTW, I'd be pretty impressed if it did, but not all that
surprised ;-).
But I'll happily concede the point, and prove it by knocking up a patch for
it over the weekend (unless anyone else particularly wants to).
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
