On Tue, Apr 8, 2025, at 5:25 PM, Nathan Bossart wrote: > On Tue, Apr 08, 2025 at 04:44:02PM +0530, Amit Kapila wrote: > > On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart <nathandboss...@gmail.com> > > wrote: > >> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote: > >> > Can we dodge adding this push call if we restrict the length of the > >> > origin name to some reasonable limit like 256 or 512 and avoid the > >> > need of toast altogether? > >> > >> We did consider just removing pg_replication_origin's TOAST table earlier > >> [0], but we decided against it at that time. Maybe it's worth > >> reconsidering... > > > > I don't see any good reason in that email for not removing the TOAST > > table for pg_replication_origin. I would prefer to remove it rather > > than add protection related to its access. > > The only reason I can think of is that folks might have existing > replication origins with extremely long names that would cause upgrades to > fail. While I think it would be probably be okay to remove the TOAST table > and restrict origin names to 512 bytes (like we did for password hashes in > commit 8275325), folks routinely complain about NAMEDATALEN, so I think we > should be cautious here.
The logical replication creates origin names as pg_SUBOID_RELID or pg_SUBOID. It means the maximum origin name is 24. This limited origin name also applies to pglogical that limits the name to 54 IIRC. I think that covers the majority of the logical replication setups. There might be a small number of custom logical replication systems that possibly use long names for replication origin. I've never seen a replication origin name longer than NAMEDATALEN. If you consider that the maximum number of replication origin is limited to 2 bytes (65k distinct names), it is reasonable to restrict the replication origin names to 512 due to the high number of combinations. We generally expects that a catalog string uses "name" as type if it is an identifier; it could be the case for roname if author decided to be strict. This additional TOAST table has no or rare use. +1 for removing it. It is one less file, one less table and one less index; in short, one less source of data corruption. ;) -- Euler Taveira EDB https://www.enterprisedb.com/
