Re: max_locks_per_transaction v18

On Mon, 18 Aug 2025 at 15:13, James Pang <jamespang886(at)gmail(dot)com> wrote:
> We are planning to database upgrade, and evaluate PGv18 as next new major version. Based on new release notes, one question about, "Improve the locking performance of queries that access many relations ".
> new share_lock_table size is based on max_locks_per_transaction, our production databases have 8k-10k connections, and existing PGV14 stable running there long time. Is it possible to get a new GUC instead of reusing "max_locks_per_transaction", so we can more flexible control on our production environment, for example, we want to keep similar value as existing "shared_lock_table" size related, and separate control of "max_locks_per_transaction".

What do you have max_locks_per_transaction set to?

Can you demonstrate that having a separate GUC for the fast-path
locking slots is useful? Have you benchmarked this? If so, I suspect
the results of that will be more likely to convince us than an
evidence-less request.

One thing to note is that the change Tomas made will never result in
there before fewer fastpath locking slots than there were previously,
so I doubt you'll find any regressions here, which might mean there's
not much chance we'll adjust this at this hour for v18.

David