On Fri, Jul 10, 2020 at 7:23 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Thu, 9 Jul 2020 at 12:11, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada
> > <masahiko.sawada@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. I think you
might want to remove the indexing stuff you have added for faster
search as discussed above.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
