Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
От | Alexander Korotkov |
---|---|
Тема | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Дата | |
Msg-id | CAPpHfdt_HFxNKFbSUaDg5QHxzKcvPBB5OhRengRpVDp6ubdrFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Moving relation extension locks out of heavyweight lockmanager (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Moving relation extension locks out of heavyweightlock manager
|
Список | pgsql-hackers |
On Tue, Jun 5, 2018 at 12:48 PM Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote: > Workload is combination of inserts and selects. > Looks like shared locks obtained by select cause starvation of inserts, trying to get exclusive relation extension lock. > The problem is fixed by fair lwlock patch, implemented by Alexander Korotkov. This patch prevents granting of shared lockif wait queue is not empty. > May be we should use this patch or find some other way to prevent starvation of writers on relation extension locks forsuch workloads. Fair lwlock patch really fixed starvation of exclusive lwlock waiters. But that starvation happens not on relation extension lock – selects don't get shared relation extension lock. The real issue there was not relation extension lock itself, but the time spent inside this lock. It appears that buffer replacement happening inside relation extension lock is affected by starvation on exclusive buffer mapping lwlocks and buffer content lwlocks, caused by many concurrent shared lockers. So, fair lwlock patch have no direct influence to relation extension lock, which is naturally not even lwlock... I'll post fair lwlock path in a separate thread. It requires detailed consideration and benchmarking, because there is a risk of regression on specific workloads. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: