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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
