Re: max_locks_per_transaction v18 - Mailing list pgsql-hackers

From James Pang
Subject Re: max_locks_per_transaction v18
Date
Msg-id CAHgTRfdZETQau=4u6r8g_-aq7C45dUSwLdHvcP0s6WEcYOmFBQ@mail.gmail.com
Whole thread Raw
In response to Re: max_locks_per_transaction v18  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
  thanks for you clarification about additional memory calculations:  for 10k connections , 5625kB maybe fine.   I justed looked through the discussions about memory allocation "https://www.postgresql.org/message-id/cba2406a-66bb-41ac-b1cf-bb898596e0e1%40vondra.me", I feel confused about the statement "the memory 1000 connections 80MB there" 

Thanks, 

James 
David Rowley <dgrowleyml@gmail.com> 於 2025年8月18日週一 下午2:58寫道:
On Mon, 18 Aug 2025 at 18:23, James Pang <jamespang886@gmail.com> wrote:
>     not tested and any regression found either, with 10k connections, and  "max_locks_per_transaction=128",  it need about more than 1GB extra memory,right?  per my understanding, max_locks_per_transaction is the max locked objects in a transaction (that's not an average locked objects at the same time among all connections),  but for past-path-lock slots, the memory will be allocated based on this parameter after client connection  established, right? so, even no so many fast lock slots needed, for 10k connections, extra memory got allocated there.  We may test that in our environment, and update then if anything found.

Can you share how you came to 1GB extra?

By my calculations, I believe it's an extra 5625 kB total for the
entire instance.

select pg_size_pretty((max_locks_per_xact / 16 * 8 +
max_locks_per_xact / 16 * 4 * 16) * connections::numeric) from
(values(128,10000)) v(max_locks_per_xact, connections);

David

pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Chao Li
Date:
Subject: Re: Remove redundant assignment of a variable in function AlterPublicationTables