On Fri, Jul 31, 2015 at 10:11 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jul 29, 2015 at 11:48 PM, Andres Freund <and...@anarazel.de> wrote: > > > > On 2015-07-29 12:54:59 -0400, Robert Haas wrote: > > > I would try to avoid changing lwlock.c. It's pretty easy when so > > > doing to create mechanisms that work now but make further upgrades to > > > the general lwlock mechanism difficult. I'd like to avoid that. > > > > I'm massively doubtful that re-implementing parts of lwlock.c is the > > better outcome. Then you have two different infrastructures you need to > > improve over time. > > I agree and modified the patch to use 32-bit atomics based on idea > suggested by Robert and didn't modify lwlock.c.
While looking at patch, I found that the way it was initialising the list to be empty was wrong, it was using pgprocno as 0 to initialise the list, as 0 is a valid pgprocno. I think we should use a number greater that PROCARRAY_MAXPROC (maximum number of procs in proc array). Apart from above fix, I have modified src/backend/access/transam/README to include the information about the improvement this patch brings to reduce ProcArrayLock contention. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
group_xid_clearing_at_trans_end_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
