Re: Reduce ProcArrayLock contention - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Reduce ProcArrayLock contention
Date
Msg-id CABOikdMsjTiUodj42rq6ZFczNVwmyaakRd5gaNR+wq5ME9GEhQ@mail.gmail.com
Whole thread Raw
In response to Re: Reduce ProcArrayLock contention  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reduce ProcArrayLock contention  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Tue, Aug 4, 2015 at 8:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:


I spent some time looking at this patch today and found that a good
deal of cleanup work seemed to be needed.  Attached is a cleaned-up
version which makes a number of changes:


I'm not entirely happy with the name "nextClearXidElem" but apart from
that I'm fairly happy with this version. 

Can we just call it "nextAtomicListElem" and the one in PROC_HDR "headAtomicList" or something like that? Basically we can use the same list later at other places requiring similar treatment. I don't see them anything specific to clearXid stuff. Rather it is just some sort of atomic list of PGPROC

I actually even thought if we can define some macros or functions to work on atomic list of PGPROCs. What we need is:

- Atomic operation to add a PGPROC to list list and return the head of the list at the time of addition
- Atomic operation to delink a list from the head and return the head of the list at that time
- Atomic operation to remove a PGPROC from the list and return next element in the list
- An iterator to work on the list.

This will avoid code duplication when this infrastructure is used at other places. Any mistake in the sequence of read/write/cas can lead to a hard to find bug.

Having said that, it might be ok if we go with the current approach and then revisit this if and when other parts require similar logic.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Robert Haas
Date:
Subject: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );