Hey, all, I went ahead and made a patch for introducing a new GUC variable, max_replication_origins, to replace the awkward re-use of max_replication_slots.
I'm mostly indifferent whether a new GUC variable is necessary, or simply just updating the existing documentation (the first patch I sent) is sufficient, but one of them should definitely be done to clear up the confusion. - Paul On Tue, Feb 16, 2021 at 1:03 PM Paul Martinez <paul...@google.com> wrote: > Hey, all, > > The configuration parameter max_replication_slots is most notably used > to control how many replication slots can be created on a server, but it > also controls how many replication origins can be tracked on the > subscriber side. > > This is noted in the Configuration Settings section in the Logical > Replication Chapter [1], but it is not mentioned in the documentation > the parameter itself [2]. > > The attached patch adds an extra paragraph explaining its effect on > subscribers. > > > Using max_replication_slots for sizing the number available of > replication origin states is a little odd, and is actually noted twice > in the source code [3] [4]: > > > XXX: Should we use a separate variable to size this rather than > > max_replication_slots? > > > XXX: max_replication_slots is arguably the wrong thing to use, as here > > we keep the replay state of *remote* transactions. But for now it > > seems sufficient to reuse it, rather than introduce a separate GUC. > > This is a different usage of max_replication_slots than originally > intended, managing resource usage on the subscriber side, rather than > the provider side. This manifests itself in the awkwardness of the > documentation, where max_replication_slots is only listed in the Sending > Server section, and not mentioned in the Subscribers section. > > Given this, I think introducing a new parameter would make sense > (max_replication_origins? slightly confusing because there's no limit on > the number of records in pg_replication_origins; tracking of replication > origins is displayed in pg_replication_origin_status). > > I'd be happy to make a patch for a new GUC parameter, if people think > it's worth it to separate the functionality. Until then, however, the > addition to the documentation should help prevent confusion. > > > - Paul > > [1]: https://www.postgresql.org/docs/13/logical-replication-config.html > [2]: > https://www.postgresql.org/docs/13/runtime-config-replication.html#GUC-MAX-REPLICATION-SLOTS > [3]: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/logical/origin.c;h=685eaa6134e7cad193b583ff28284d877a6d8055;hb=HEAD#l162 > [4]: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/logical/origin.c;h=685eaa6134e7cad193b583ff28284d877a6d8055;hb=HEAD#l495 >
max_replication_origins_v00.diff
Description: Binary data
