Re: Maximum number of exclusive locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Maximum number of exclusive locks
Date: 2016-09-13 20:45:30
Message-ID: 28478.1473799530@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Having said that, the amount of slop involved is only enough for a
>> few hundred lock entries. Not sure how you're managing to get to
>> nearly 20000 extra entries.

> The code assumes every locked object will have 2 processes that hold it (or
> wait for it). If you actually only have one holder for each locked object,
> that frees up a lot of memory to hold more locked objects.

Ah, right, the key is the difference between the init and max table sizes
in InitLocks. So his test case is chewing up all the spare space but more
of it is going into the LOCK table than the PROCLOCK table, compared to
the estimates. Possibly would leave him a bit starved for PROCLOCKs later.
I'm disinclined to change that initialization code though, since the point
is to try to adapt to variations in the holders-per-lock ratio for
different workloads.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ashish Chauhan 2016-09-13 21:31:45 pgpoolAdmin - pgmgt.conf.php write denied error
Previous Message Jeff Janes 2016-09-13 20:25:57 Re: Maximum number of exclusive locks