From: Euler Taveira <euler@eulerto.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers@lists.postgresql.org, "Andres Freund" <andres@anarazel.de>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Subject: Re: speed up a logical replica setup
Date: Thu, 04 Jan 2024 12:48:03 -0300
Message-ID: <9fd3018d-0e5f-4507-aee6-efabfb5a4440@app.fastmail.com> (raw)
In-Reply-To: <CAA4eK1+0Ym6-WO29gbBK4FT7C1qsXHfSY1T7Wqd4ctdJw9kTcA@mail.gmail.com>
References: <5ac50071-f2ed-4ace-a8fd-b892cffd33eb@www.fastmail.com>
<4710d895-689a-4ae6-b8e3-344286dbf970@app.fastmail.com>
<da078f11-d2de-420e-9611-f3b7d4dadd9a@eisentraut.org>
<ZUrEclC-uZV-rGd2@paquier.xyz>
<96e3b739-d63d-4d35-90a3-7869465b7167@eisentraut.org>
<ZU1nR5KMZtSTEQDf@paquier.xyz>
<e02a2c17-22e5-4ba6-b788-de696ab74f1e@app.fastmail.com>
<CAA4eK1+yUsZ7SDU-NDfcgdVQM4UOTK_bhLx2z1a0CHkEidvHow@mail.gmail.com>
<270ad9b8-9c46-40c3-b6c5-3d25b91d3a7d@app.fastmail.com>
<CAA4eK1+0Ym6-WO29gbBK4FT7C1qsXHfSY1T7Wqd4ctdJw9kTcA@mail.gmail.com>
On Thu, Jan 4, 2024, at 2:41 AM, Amit Kapila wrote:
> So, you also seem to be saying that it is not required once
> pg_subscriber has promoted it. So, why it should be optional to remove
> physical_replication_slot? I think we must remove it from the primary
> unless there is some other reason.
My point is to *always* remove the primary_slot_name on primary.
> My point is to not have an additional slot and keep a comment
> indicating that we need an extra slot once we add pg_basebackup
> support.
Got it.
> > 3. How about sync slots on the physical standby if present? Do we want
> > to retain those as it is or do we need to remove those? We are
> > actively working on the patch [1] for the same.
> >
> >
> > I didn't read the current version of the referred patch but if the proposal is
> > to synchronize logical replication slots iif you are using a physical
> > replication, as soon as pg_subscriber finishes the execution, there won't be
> > synchronization on these logical replication slots because there isn't a
> > physical replication anymore. If the goal is a promotion, the current behavior
> > is correct because the logical replica will retain WAL since it was converted.
> >
>
> I don't understand what you mean by promotion in this context. If
> users want to simply promote the standby then there is no need to do
> additional things that this tool is doing.
ENOCOFFEE. s/promotion/switchover/
> > However, if you are creating a logical replica, this WAL retention is not good
> > and the customer should eventually remove these logical replication slots on
> > the logical replica.
> >
>
> I think asking users to manually remove such slots won't be a good
> idea. We might want to either remove them by default or provide an
> option to the user.
Am I correct that the majority of the use cases these replication slots will be
useless? If so, let's remove them by default and add an option to control this
behavior (replication slot removal).
--
Euler Taveira
EDB https://www.enterprisedb.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: euler@eulerto.com, amit.kapila16@gmail.com, michael@paquier.xyz, peter@eisentraut.org, andres@anarazel.de, ashutosh.bapat.oss@gmail.com
Subject: Re: speed up a logical replica setup
In-Reply-To: <9fd3018d-0e5f-4507-aee6-efabfb5a4440@app.fastmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox