On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Wed, 8 Jul 2020 at 16:04, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Jul 8, 2020 at 11:28 AM Masahiko Sawada > > <masahiko.saw...@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
