On 2021-08-03 16:56:12 +0900, Masahiko Sawada wrote: > 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.
Indeed. It's already kinda painful to maintain the shared memory stats patch, no need to make it harder... > 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. I'd keep it in sync with what's there right now. Greetings, Andres Freund
