From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: "wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>,
        "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c
In-reply-to: <20230222170737.GA10734@nathanxps13>
References: <OS3PR01MB6275BDD09C9B875C65FCC5AB9EA39@OS3PR01MB6275.jpnprd01.prod.outlook.com> <20230222003716.GA8100@nathanxps13> <OSZPR01MB627839B978B5735773D864FD9EAA9@OSZPR01MB6278.jpnprd01.prod.outlook.com> <20230222170737.GA10734@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Wed, 22 Feb 2023 09:07:37 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1515916.1680623251.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 04 Apr 2023 11:47:31 -0400
Message-ID: <1515917.1680623251@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1515917.1680623251%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Feb 22, 2023 at 12:40:07PM +0000, wangw.fnst@fujitsu.com wrote:
>> After some rethinking, I think users can easily get exact value accordi=
ng to
>> exact formula, and I think using accurate formula can help users adjust
>> max_locks_per_transaction or max_predicate_locks_per_transaction if nee=
ded. So,
>> I used the exact formulas in the attached v2 patch.

> IMHO this is too verbose.

Yeah, it's impossibly verbose.  Even the current wording does not fit
nicely in pg_settings output.

> Perhaps it could be simplified to something like
> 	The shared lock table is sized on the assumption that at most
> 	max_locks_per_transaction objects per eligible process or prepared
> 	transaction will need to be locked at any one time.

I like the "per eligible process" wording, at least for guc_tables.c;
or maybe it could be "per server process"?  That would be more
accurate and not much longer than what we have now.

I've got mixed emotions about trying to put the exact formulas into
the SGML docs either.  Space isn't such a constraint there, but I
think the info would soon go out of date (indeed, I think the existing
wording was once exactly accurate), and I'm not sure it's worth trying
to maintain it precisely.

One reason that I'm not very excited about this is that in fact the
formula seen in the source code is not exact either; it's a lower
bound for how much space will be available.  That's because we throw
in 100K slop at the bottom of the shmem sizing calculation, and a
large chunk of that remains available to be eaten by the lock table
if necessary.

			regards, tom lane