Re: Separate GUC for replication origins

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>
Cc: "vignesh C" <vignesh21(at)gmail(dot)com>, "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2025-03-18 01:05:16
Message-ID: 63cecd67-6a54-4b2d-bef1-b25a34f9c48c@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 17, 2025, at 8:44 PM, Masahiko Sawada wrote:
> I would suggest putting the new max_active_replication_origins after
> max_parallel_apply_workers_per_subscription as both
> max_sync_workers_per_subscription and
> max_parallel_apply_workers_per_subscription are related to
> max_logical_replication_workers.

Good point. Looking at the documentation, the old max_replication_slots
parameter was the first one in that section so I decided to use the same order
for the postgresql.conf.sample.

--
Euler Taveira
EDB https://www.enterprisedb.com/

Attachment Content-Type Size
v7-0001-Separate-GUC-for-replication-origins.patch text/x-patch 26.9 KB
v7-0002-max_active_replication_origins-defaults-to-10.patch text/x-patch 4.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-03-18 02:06:34 Re: maintenance_work_mem = 64kB doesn't work for vacuum
Previous Message Sungwoo Chang 2025-03-18 01:05:07 Re: dsm_registry: Add detach and destroy features