From: | Paul Martinez <paulmtz(at)google(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | [PATCH] Note effect of max_replication_slots on subscriber side in documentation. |
Date: | 2021-02-16 21:03:53 |
Message-ID: | CACqFVBZgwCN_pHnW6dMNCrOS7tiHCw6Retf_=U2Vvj3aUSeATw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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_slots_subscriber_doc_v00.diff | application/octet-stream | 1.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-02-16 22:05:22 | Re: Tid scan improvements |
Previous Message | Isaac Morland | 2021-02-16 20:59:41 | Re: Trigger execution role |