On Fri, Mar 11, 2016 at 12:04 AM, Petr Jelinek <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.. And other waiter will not get lock unless first waiter extend all blocks and release the locks. One possible case is as soon as we extend the blocks new requester directly find in FSM and don't come for lock, and old waiter after getting lock don't find in FSM, But IMHO in such cases, also its good that other waiter also extend more blocks (because this can happen when request flow is very high). -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
