On Fri, Jul 10, 2020 at 2:42 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Jul 10, 2020 at 7:23 AM Masahiko Sawada > <masahiko.saw...@2ndquadrant.com> wrote: > > > > On Thu, 9 Jul 2020 at 12:11, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada > > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > > > > > > > I think that using oids has another benefit that we don't need to send > > > > slot name to the stats collector along with the stats. Since the > > > > maximum size of slot name is NAMEDATALEN and we don't support the > > > > pgstat message larger than PGSTAT_MAX_MSG_SIZE (1000 bytes), if the > > > > user wants to increase NAMEDATALEN they might not be able to build. > > > > > > > > > > I think NAMEDATALEN is used for many other objects as well and I don't > > > think we want to change it in foreseeable future, so that doesn't > > > sound to be a good reason to invent OIDs for slots. OTOH, I do > > > understand it would be better to send OIDs than names for slots but I > > > am just not sure if it is a good idea to invent a new way to generate > > > OIDs (which is different from how we do it for other objects in the > > > system) for this purpose. > > > > I'm concerned that there might be users who are using custom > > PostgreSQL that increased NAMEDATALEN for some reason. But indeed, I > > also agree with your concerns. So perhaps we can go with the current > > PoC patch approach as the first version (i.g., sending slot drop > > message to stats collector). When we need such a unique identifier > > also for other purposes, we will be able to change this feature so > > that it uses that identifier for this statistics reporting purpose. > > > > Okay, feel to submit the version atop my revert patch. >
Attached, please find the rebased version. I have kept prorows as 10 instead of 100 for pg_stat_get_replication_slots because I don't see much reason for keeping the value more than the default value of max_replication_slots. As we are targeting this patch for PG14, so I think we can now add the functionality to reset the stats as well. What do you think? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
spill_stats_v1.patch
Description: Binary data
