Re: Reduce ProcArrayLock contention

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Reduce ProcArrayLock contention
Дата
Msg-id CABOikdMsjTiUodj42rq6ZFczNVwmyaakRd5gaNR+wq5ME9GEhQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reduce ProcArrayLock contention  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Reduce ProcArrayLock contention
Список 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 по дате отправления: