On 2024-Feb-07, Dilip Kumar wrote: > On Tue, Feb 6, 2024 at 8:55 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > > > I made CLOGShmemBuffers, CommitTsShmemBuffers and SUBTRANSShmemBuffers > > compute a number that's multiple of SLRU_BANK_SIZE. But it's a crock, > > because we don't have that macro at that point, so I just used constant > > 16. Obviously need a better solution for this. > > If we define SLRU_BANK_SIZE in slur.h then we can use it here right, > because these files are anyway include slur.h so.
Sure, but is that really what we want? > > I've been wondering whether we should add a "slru" to the name of the > > GUCs: > > > > commit_timestamp_slru_buffers > > transaction_slru_buffers > > etc > > I am not sure we are exposing anything related to SLRU to the user, We do -- we have pg_stat_slru already. > I mean transaction_buffers should make sense for the user that it > stores transaction-related data in some buffers pool but whether that > buffer pool is called SLRU or not doesn't matter much to the user > IMHO. Yeah, that's exactly what my initial argument was for naming these this way. But since the term slru already escaped into the wild via the pg_stat_slru view, perhaps it helps users make the connection between these things. Alternatively, we can cross-reference each term from the other's documentation and call it a day. Another painful point is that pg_stat_slru uses internal names in the data it outputs, which obviously do not match the new GUCs. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Uno puede defenderse de los ataques; contra los elogios se esta indefenso"