Re: Rationalizing SInval/PGPROC data structures and locking - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Rationalizing SInval/PGPROC data structures and locking
Date
Msg-id 20050519004550.GC12557@surnet.cl
Whole thread Raw
In response to Rationalizing SInval/PGPROC data structures and locking  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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!"
 


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Two-phase commit issues
Next
From: Andrew Dunstan
Date:
Subject: Re: Learning curves and such (was Re: pgFoundry)