pgsql: Change default of max_locks_per_transactions to 128

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Change default of max_locks_per_transactions to 128
Date: 2026-04-03 17:32:04
Message-ID: E1w8iNH-002maX-1C@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Change default of max_locks_per_transactions to 128

The previous commits reduced the amount of memory available for locks
by eliminating the "safety margins" and by settling the split between
LOCK and PROCLOCK tables at startup. The allocation is now more
deterministic, but it also means that you often hit one of the limits
sooner than before. To compensate for that, bump up
max_locks_per_transactions from 64 to 128. With that there is a little
more space in the both hash tables than what was the effective maximum
size for either table before the previous commits.

This only changes the default, so if you had changed
max_locks_per_transactions in postgresql.conf, you will still have
fewer locks available than before for the same setting value. This
should be noted in the release notes. A good rule of thumb is that if
you double max_locks_per_transactions, you should be able to get as
many locks as before.

Reviewed-by: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Reviewed-by: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Discussion: https://www.postgresql.org/message-id/e07be2ba-856b-4ff5-8313-8b58b6b4e4d0@iki.fi

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/79534f90657c37c5238e5341a111dedd26d9c0fb

Modified Files
--------------
doc/src/sgml/config.sgml | 2 +-
src/backend/utils/init/postinit.c | 2 +-
src/backend/utils/misc/guc_parameters.dat | 2 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/bin/pg_resetwal/pg_resetwal.c | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Nathan Bossart 2026-04-03 19:03:38 pgsql: Refactor relation_needs_vacanalyze().
Previous Message Amit Langote 2026-04-03 06:44:24 Re: pgsql: Optimize fast-path FK checks with batched index probes