Re: Rationalizing SInval/PGPROC data structures and locking

On Wed, May 18, 2005 at 08:16:47PM -0400, Tom Lane wrote:

> The reason things got this way is that we've been loading more and more
> functionality onto the array of PGPROC pointers that is, more or less
> incidentally, maintained by sinval.c. I'm thinking that it'd be a good
> idea to remove most of that stuff from sinval.c and put it into a
> separate module that maintains its own array of PGPROC pointers with a
> separate lock. There's no reason why, eg, GetSnapshotData needs to
> conflict with transfer of SI inval messages, which is what SInvalLock
> was originally designed to protect.

I agree this is a good idea. I might mention that I was going to put
some things in the PGPROC array for MultiXactId, then saw that getting
the SInvalLock for operations on those would abuse the lock too much --
that's when I decided to move them to a separate struct.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
That's because in Europe they call me by name, and in the US by value!"