From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reduce ProcArrayLock contention |
Date: | 2015-08-05 13:08:52 |
Message-ID: | CA+TgmobVYjUM-HsVuTqmeuSUR4YdrvmBEd7h+8W2MYF7WWDQTg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 5, 2015 at 8:30 AM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
> 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.
The third operation is unsafe because of the A-B-A problem. That's
why the patch clears the whole list instead of popping an individual
entry.
> 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.
Yeah, I don't think we should assume this will be a generic facility.
We can make it one later if needed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-08-05 13:46:36 | Re: Raising our compiler requirements for 9.6 |
Previous Message | Andres Freund | 2015-08-05 13:08:29 | Re: Raising our compiler requirements for 9.6 |