On Tue, Aug 3, 2021 at 3:17 PM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Tue, 3 Aug 2021 12:40:23 +0900, Masahiko Sawada <sawada.m...@gmail.com> > wrote in > > Hi all, > > > > While working on a patch adding new stats, houzj pointed out that > > 'len' function arguments of all pgstat_recv_* functions are not used > > at all. Looking at git history, pgstat_recv_* functions have been > > having ‘len’ since the stats collector was introduced by commit > > 140ddb78fe 20 years ago but it was not used at all even in the first > > commit. It seems like the improvements so far for the stats collector > > had pgstat_recv_* function have ‘len’ for consistency with the > > existing pgstat_recv_* functions. Is there any historical reason for > > having 'len' argument? Or can we remove them? > > > > I've attached the patch that removes 'len' from all pgstat_recv_* functions. > > I at the first look thought that giving "len" as a parameter is > reasonable as message-processing functions, but the given message > struct contains the same value and the functions can refer to the > message length without the parameter if they want. So I'm +-0 for the > removal. > > It applies cleanly on the master and compiled without an error. > > That being said, I'm not sure it is worthwhile to change parameters of > going-to-be-removed functions (if shared-memory stats collector is > successfully introduced).
Good point. I'm not going to insist on removing them but I got confused a bit whether or not I should add 'len' when writing a new pgstat_recv_* function. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
