From: | "wangw(dot)fnst(at)fujitsu(dot)com" <wangw(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(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 12:40:07 |
Message-ID: | OSZPR01MB627839B978B5735773D864FD9EAA9@OSZPR01MB6278.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 22, 2023 at 8:37 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> 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...
Thanks very much for your careful review.
Yes, you are right. I think the formulas in the v1 patch are all approximations.
I think the exact formula (see function InitializeMaxBackends) is:
```
max_locks_per_transaction * (max_connections + autovacuum_max_workers + 1 +
max_worker_processes + max_wal_senders +
max_prepared_transactions)
```
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.
Regards,
Wang Wei
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Fix-the-description-of-shared-lock-table-size-and.patch | application/octet-stream | 3.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Melih Mutlu | 2023-02-22 12:51:35 | Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication |
Previous Message | Hayato Kuroda (Fujitsu) | 2023-02-22 12:34:24 | RE: [Proposal] Add foreign-server health checks infrastructure |