On 11/03/16 02:44, Dilip Kumar wrote:
On Fri, Mar 11, 2016 at 12:04 AM, Petr Jelinek <p...@2ndquadrant.com <mailto:p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
