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

On Tues, Apr 4, 2023 at 23:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> > On Wed, Feb 22, 2023 at 12:40:07PM +0000, wangw(dot)fnst(at)fujitsu(dot)com wrote:
> >> After some rethinking, I think users can easily get exact value according to
> >> exact formula, and I think using accurate formula can help users adjust
> >> max_locks_per_transaction or max_predicate_locks_per_transaction if
> needed. 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.

Thanks both for sharing your opinions.
I agree that verbose descriptions make maintenance difficult.
For consistency, I unified the formulas in guc_tables.c and pg-doc into the same
suggested short formula. Attach the new patch.

> 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.

Thanks for sharing this.
Since no one has reported related issues, I'm also fine to close this entry if
this related modification is not necessary.

Regards,
Wang Wei