Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> It doesn't hurt to keep the locations and code as much in sync as
>> possible. I think Tom's idea to move the information into the PGPROC
>> entry is the winner and does not need any OS specific handling.
>
> Actually, on further reflection a separate array to store PIDs and
> cancel keys is probably a better idea. If we put this stuff in PGPROC
> then the postmaster will need to be able to obtain the ProcStructLock
> (or whatever it's called this week) in order to examine/modify that
> data structure. That gets us into the usual concerns about backend bugs
> locking up the postmaster, etc. But if it's a separate array then we
> can just have the rule that no one but the postmaster gets to write in it.
>
> I still think it's unnecessary to make a separate shmem segment for it,
> though.
I'd like to avoid the additional shmem segment if possible. The
postmaster can keep the stuff he needs in local memory. I did not mean
to rip everything out of postmaster local memory, and that little bit of
redundancy does not hurt. The pid's of processes aren't likely to change
very often.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
