On Wed, Feb 22, 2023 at 12:40:07PM +0000, wangw.fnst@fujitsu.com wrote:
> On Wed, Feb 22, 2023 at 8:37 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> 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.
IMHO this is too verbose. 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.
But if others disagree and think the full formula is appropriate, I'm fine
with it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com