Thread: Practical maximum max_locks_per_transaction?

Practical maximum max_locks_per_transaction?

From
Ron
Date:
v9.6.24 (being retired next year)

https://www.postgresql.org/docs/9.6/runtime-config-locks.html

"The default, 64, has historically proven sufficient, but you might need to raise this value if you have queries that touch many different tables in a single transaction, e.g., query of a parent table with many children."

How "raised" is too raised?  I just had to increase max_locks_per_transaction from 640 to 1024 on an instance with many child tables and against which is run many large reports.  Another instance has zero children, but had to increase the value to 1280 to prevent reports from failing.

--
Angular momentum makes the world go 'round.

Re: Practical maximum max_locks_per_transaction?

From
Tom Lane
Date:
Ron <ronljohnsonjr@gmail.com> writes:
> How "raised" is too raised?  I just had to increase
> max_locks_per_transaction from 640 to 1024 on an instance with many child
> tables and against which is run many large reports.  Another instance has
> zero children, but had to increase the value to 1280 to prevent reports from
> failing.

max_locks_per_transaction in isolation means nothing.  What counts
is the product max_locks_per_transaction * max_connections, which is
(more or less) the number of slots allocated in the shared lock table.

Having said that, you can probably make it as big as you want
on any reasonably modern machine.  I wouldn't blink at a few
million locktable entries, at least not on 64-bit hardware.

            regards, tom lane



Re: Practical maximum max_locks_per_transaction?

From
Ron
Date:
On 11/25/22 17:56, Tom Lane wrote:
> Ron <ronljohnsonjr@gmail.com> writes:
>> How "raised" is too raised?  I just had to increase
>> max_locks_per_transaction from 640 to 1024 on an instance with many child
>> tables and against which is run many large reports.  Another instance has
>> zero children, but had to increase the value to 1280 to prevent reports from
>> failing.
> max_locks_per_transaction in isolation means nothing.  What counts
> is the product max_locks_per_transaction * max_connections, which is
> (more or less) the number of slots allocated in the shared lock table.
>
> Having said that, you can probably make it as big as you want
> on any reasonably modern machine.  I wouldn't blink at a few
> million locktable entries, at least not on 64-bit hardware.

Really good to know.  I wonder how that can be worded in the documentation.

-- 
Angular momentum makes the world go 'round.