On 11/03/16 02:44, Dilip Kumar wrote:
>
> On Fri, Mar 11, 2016 at 12:04 AM, Petr Jelinek <petr@2ndquadrant.com
> <mailto:petr@2ndquadrant.com>> wrote:
>
> Thanks for looking..
>
> Those look good. The patch looks good in general now. I am bit
> scared by the lockWaiters * 20 as it can result in relatively big
> changes in rare corner cases when for example a lot of backends were
> waiting for lock on relation and suddenly all try to extend it. I
> wonder if we should clamp it to something sane (although what's sane
> today might be small in couple of years).
>
>
> But in such condition when all are waiting on lock, then at a time only
> one waiter will get the lock and that will easily count the lock waiter
> and extend in multiple of that. And we also have the check that if any
> waiter get the lock it will first check in FSM that anybody else have
> added one block or not..
>
I am not talking about extension locks, the lock queue can be long
because there is concurrent DDL for example and then once DDL finishes
suddenly 100 connections that tried to insert into table will try to get
extension lock and this will add 2000 new pages when much fewer was
actually needed. I guess that's fine as it's corner case and it's only
16MB even in such extreme case.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services