Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: "wangw(dot)fnst(at)fujitsu(dot)com" <wangw(dot)fnst(at)fujitsu(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c
Date: 2023-02-22 00:37:16
Message-ID: 20230222003716.GA8100@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Feb 15, 2023 at 08:16:43AM +0000, wangw(dot)fnst(at)fujitsu(dot)com wrote:
> When I refer to the GUC "max_locks_per_transaction", I find that the description
> of the shared lock table size in pg-doc[1] is inconsistent with the code
> (guc_table.c). BTW, the GUC "max_predicate_locks_per_xact" has similar problems.
> I think the descriptions in pg-doc are correct.
> - GUC "max_locks_per_transaction"
> Please refer to the macro "NLOCKENTS" used to obtain max_table_size in the
> function InitLocks.
> - GUC "max_predicate_locks_per_xact"
> Please refer to the macro "NPREDICATELOCKTARGETENTS" used to obtain
> max_table_size in the function InitPredicateLocks.

The GUC description for max_locks_per_transaction was first added in
b700a67 (July 2003). Neither the GUC description nor the documentation was
updated when max_prepared_transactions was introduced in d0a8968 (July
2005). However, the documentation was later fixed via 78ef2d3 (August
2005). It looks like the GUC description for
max_predicate_locks_per_transaction was wrong from the start. In dafaa3e
(February 2011), the GUC description does not include
max_prepared_transactions, but the documentation does.

It's interesting that the documentation cites max_connections, as the
tables are sized using MaxBackends, which includes more than just
max_connections (e.g., autovacuum_max_workers, max_worker_processes,
max_wal_senders). After some digging, I see that MaxBackends was the
original variable used for max_connections (which was called max_backends
until 648677c (July 2000)), and it wasn't until autovacuum_max_workers was
introduced in e2a186b (April 2007) before max_connections got its own
MaxConnections variable and started diverging from MaxBackends.

So, even with your patch applied, I don't think the formulas are correct.
I don't know if it's worth writing out the exact formula, though. It
doesn't seem to be kept up-to-date, and I don't know if users would choose
different values for max_locks_per_transaction if it _was_ updated.
Perhaps max_connections is a good enough approximation of MaxBackends most
of the time...

Nathan Bossart
Amazon Web Services:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-02-22 01:00:04 Re: Time delayed LR (WAS Re: logical replication restrictions)
Previous Message Thomas Munro 2023-02-22 00:10:35 Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"