Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c
Date
Msg-id 20230222003716.GA8100@nathanxps13
Whole thread Raw
In response to Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Responses RE: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c
List pgsql-hackers
On Wed, Feb 15, 2023 at 08:16:43AM +0000, wangw.fnst@fujitsu.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: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"
Next
From: Peter Smith
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)