Re: [PATCH] Note effect of max_replication_slots on subscriber side in documentation.

From: Paul Martinez <paulmtz(at)google(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Note effect of max_replication_slots on subscriber side in documentation.
Date: 2021-02-24 19:55:05
Message-ID: CACqFVBbd1nD+=H5k2f=jP0vKu00dHKmHKy2_6dtR0D4Gh9dCbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <paulmtz(at)google(dot)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
>

Attachment Content-Type Size
max_replication_origins_v00.diff application/octet-stream 12.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2021-02-24 19:59:19 Re: Asynchronous and "direct" IO support for PostgreSQL.
Previous Message John Naylor 2021-02-24 19:35:18 Re: non-HOT update not looking at FSM for large tuple update