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:
> >
> > On Wed, 8 Jul 2020 at 16:04, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Jul 8, 2020 at 11:28 AM Masahiko Sawada
> > > <masahiko.sawada@2ndquadrant.com> wrote:
> > > >
> > > > >
> > > > > If we need them to be persistent across time like that, perhaps we simply need to assign oids to replication
slots?That might simplify this problem quite a bit?
> > > >
> > > > Yeah, I guess assigning oids to replication slots in the same way of
> > > > oids in system catalogs might not work because physical replication
> > > > slot can be created even during recovery. But using a
> > > > monotonically-increasing integer as id seems better and straight
> > > > forward.
> > > >
> > >
> > > But don't we need to make it WAL logged as well similar to what we do
> > > in GetNewObjectId?
> >
> > Yes. I was thinking that assigning (the maximum number of the existing
> > slot id + 1) to a new slot without WAL logging.
> >
> > > I am thinking do we really need Oids for slots or
> > > is it okay to have some approximate stats in boundary cases?
> >
> > 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.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services