Re: Move PinBuffer and UnpinBuffer to atomics

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Move PinBuffer and UnpinBuffer to atomics
Дата
Msg-id CAA4eK1+GFBMePHeMbqKUsh=Ga=q=zMNW+cieYpgV9-O6UmBH=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Move PinBuffer and UnpinBuffer to atomics  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: Move PinBuffer and UnpinBuffer to atomics  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On Tue, Dec 8, 2015 at 3:56 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
​Agree. This patch need to be carefully verified. Current experiments just show that it is promising direction for improvement. I'll come with better version of this patch.

Also, after testing on large machines I have another observation to share. For now, LWLock doesn't guarantee that exclusive lock would be ever acquired (assuming each shared lock duration is finite). It because when there is no exclusive lock, new shared locks aren't queued and LWLock state is changed directly. Thus, process which tries to acquire exclusive lock have to wait for gap in shared locks.

I think this has the potential to starve exclusive lockers in worst case.
 
But with high concurrency for shared lock that could happen very rare, say never.

We did see this on big Intel machine in practice. pgbench -S gets shared ProcArrayLock very frequently. Since some number of connections is achieved, new connections hangs on getting exclusive ProcArrayLock. I think we could do some workaround for this problem. For instance, when exclusive lock waiter have some timeout it could set some special bit which prevents others to get new shared locks.


I think timeout based solution would lead to giving priority to
exclusive lock waiters (assume a case where each of exclusive
lock waiter timesout one after another) and make shared lockers
wait and a timer based solution might turn out to be costly for
general cases where wait is not so long.  Another way could be to
check if the Exclusive locker needs to go for repeated wait for a
couple of times, then we can set such a bit.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [PROPOSAL] Backup and recovery of pg_statistic
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Include ppc64le build type for back branches