MIME-Version: 1.0
From: Koen De Groote <kdg.dev@gmail.com>
Date: Wed, 5 Jun 2024 00:55:42 +0200
Message-ID: <CAGbX52FxL9eR=jmS3ACgRC=tEm=xj_xMmFoOxO+wVA+oURW=kA@mail.gmail.com>
Subject: Questions on logical replication
To: PostgreSQL General <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000029aba3061a185a7d"
Archived-At: <https://www.postgresql.org/message-id/CAGbX52FxL9eR%3DjmS3ACgRC%3DtEm%3Dxj_xMmFoOxO%2BwVA%2BoURW%3DkA%40mail.gmail.com>
Precedence: bulk

--00000000000029aba3061a185a7d
Content-Type: text/plain; charset="UTF-8"

I recently read the entire documentation on logical replication, but am
left with a question on the buildup of WAL

On this page:
https://www.postgresql.org/docs/current/logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-SLOT

It is written: " When dropping a subscription, the remote host is not
reachable. In that case, disassociate the slot from the subscription
using ALTER
SUBSCRIPTION before attempting to drop the subscription. If the remote
database instance no longer exists, no further action is then necessary.
If, however, the remote database instance is just unreachable, the
replication slot (and any still remaining table synchronization slots)
should then be dropped manually; otherwise it/they would continue to
reserve WAL and might eventually cause the disk to fill up. Such cases
should be carefully investigated."


Assuming a situation where I add tables 1 at a time to the publisher, and
refresh the subscription every time.

What happens if I shut down the subscriber database for a while? The
subscription isn't dropped, so am I reading it right that the disk on the
publisher will slowly be filling up with WAL? Isn't that always the case if
wall is enabled?

This "cause disk to fill up" warning is quite concerning, and I'd like to
understand what could cause it and how likely it is? I thought logical
replication uses WAL by default, so doesn't that mean there has to be a log
of changes kept anyhow? Even if the WAL isn't written to disk by an
"archive_command"?

Regards,
Koen De Groote

--00000000000029aba3061a185a7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I recently read the entire documentation on logical r=
eplication, but am left with a question on the buildup of WAL</div><div><br=
></div><div>On this page: <a href=3D"https://www.postgresql.org/docs/curren=
t/logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-SL=
OT">https://www.postgresql.org/docs/current/logical-replication-subscriptio=
n.html#LOGICAL-REPLICATION-SUBSCRIPTION-SLOT</a></div><div><br></div><div>I=
t is written: &quot;
When dropping a subscription, the remote host is not reachable. In that cas=
e, disassociate the slot from the subscription using <code class=3D"gmail-c=
ommand">ALTER SUBSCRIPTION</code>
 before attempting to drop the subscription. If the remote database=20
instance no longer exists, no further action is then necessary. If,=20
however, the remote database instance is just unreachable, the=20
replication slot (and any still remaining table synchronization slots)=20
should then be dropped manually; otherwise it/they would continue to=20
reserve WAL and might eventually cause the disk to fill up. Such cases=20
should be carefully investigated.&quot;</div><div><br></div><div><br></div>=
<div>Assuming a situation where I add tables 1 at a time to the publisher, =
and refresh the subscription every time.</div><div><br></div><div>What happ=
ens if I shut down the subscriber database for a while? The subscription is=
n&#39;t dropped, so am I reading it right that the disk on the publisher wi=
ll slowly be filling up with WAL? Isn&#39;t that always the case if wall is=
 enabled?</div><div><br></div><div>This &quot;cause disk to fill up&quot; w=
arning is quite concerning, and I&#39;d like to understand what could cause=
 it and how likely it is? I thought logical replication uses WAL by default=
, so doesn&#39;t that mean there has to be a log of changes kept anyhow? Ev=
en if the WAL isn&#39;t written to disk by an &quot;archive_command&quot;?<=
/div><div><br></div><div>Regards,</div><div>Koen De Groote<br></div></div>

--00000000000029aba3061a185a7d--