Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sEdC3-002d6a-54 for pgsql-general@arkaria.postgresql.org; Tue, 04 Jun 2024 23:03:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sEdB3-0036Vp-HO for pgsql-general@arkaria.postgresql.org; Tue, 04 Jun 2024 23:02:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sEdB3-0036Vh-4h for pgsql-general@lists.postgresql.org; Tue, 04 Jun 2024 23:02:49 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sEdAz-0001hY-W5 for pgsql-general@lists.postgresql.org; Tue, 04 Jun 2024 23:02:48 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a6269885572so49565066b.1 for ; Tue, 04 Jun 2024 16:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717542165; x=1718146965; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=3wpAtyfcnE41/G3LHIRGkjUfEjQDov6lkTGkr8HhbiE=; b=MMJYMnEzmdeig/uuwCY3EZIeoR/rr5mzqfyLWCyLkgcKzSE9+y1pALOAcQHXbMPC71 00ZL/yqMCtKLnN1sTF6s/17w0b47sc0KkKlnZkQIWcKdtEKKFf+2QLkoTwp/5LCZOD48 Ej+bHeKPcCnFfLdhuThjN8WOcpoixcpteNM140o5AJcop8qatXviBu+2VFvDi4hlouU0 /ZiDbgBYnFw9Lelg6TIXyZ6/xgaKioIvhjKH7byHQ9AOCPnh6CIJwfo/ecSEv0j2D2WM Ec6Xl2F3I8lf7SPUkG4XyM5htaljpBVy4fYK9AybeVnECfT9c/8Z+SA7hOV5daw4PObp A6XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717542165; x=1718146965; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3wpAtyfcnE41/G3LHIRGkjUfEjQDov6lkTGkr8HhbiE=; b=THrIWpc5UHchEuvr3VYbyoQHIYXCVg5tMXjNMxy19A50PCS5NAHTsY12HnzQYXIiCO N5Mlj6koK+hfwUvI/+O8syHk+rKWV06EUTpiR8sAY69QAKjB4GsVWN7qYZBO6iqZ1MLB KcNnkWgNjthnz4TbCPZnIcJh52rbDcY3UthesT081oQWH8/4ylWWExIIgaGLu0xuIVrH G5M8Z1KJH3pPH5ApSfR/z+J70OKDzfz9PPNQzBfXuQQiKv8Gm1JoLVh6lkBZqYai4/T8 OFzO3/MDpQFkXpFlojtL15IooZq8q3gu30KBgJgBjKGNNxabWjQcQkFZ2LBKtRaICbXR 98jA== X-Gm-Message-State: AOJu0YzzdnK73Rx4zvGKbj44MhAcF4h3E/B3qMYtViqIQUcIYTfpoeq+ sFxBm/wcdLG3Vtu9DVoC/mAvWLf/BcMm+bAm35ncyQwwC5TI409qI+/OMIIKPMvNanSaG0OV1ma U9iyMFotQ/nc4em/59q3Ds56J3rzRycwu X-Google-Smtp-Source: AGHT+IGj9uXpfcFLFevz/xC+uPclQRJ4dgdTBLfHx7O83Tn+MNSIioC1IL1RjMzgtBI/th2VuZvwrm0t+Ge73tUo9B4= X-Received: by 2002:a17:906:705:b0:a63:3c6f:bff6 with SMTP id a640c23a62f3a-a69543cea14mr289511466b.18.1717542164752; Tue, 04 Jun 2024 16:02:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Koen De Groote Date: Wed, 5 Jun 2024 01:02:33 +0200 Message-ID: Subject: Re: Questions on logical replication To: PostgreSQL General Content-Type: multipart/alternative; boundary="0000000000009df0d4061a1872dd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000009df0d4061a1872dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reading this: https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICA= TION-SLOTS " Replication slots provide an automated way to ensure that the primary does not remove WAL segments until they have been received by all standbys, and that the primary does not remove rows which could cause a recovery conflict even when the standby is disconnected. " Am I to understand that a subscription is considered that same as a standby, in this context? On Wed, Jun 5, 2024 at 12:55=E2=80=AFAM Koen De Groote = wrote: > 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 usin= g 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 l= og > of changes kept anyhow? Even if the WAL isn't written to disk by an > "archive_command"? > > Regards, > Koen De Groote > --0000000000009df0d4061a1872dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reading this: https://www.post= gresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS

" Replication slots provide an automated way to ensure that the primary=20 does not remove WAL segments until they have been received by all=20 standbys, and that the primary does not remove rows which could cause a recovery conflict even when the standby is disconnected. "

Am I to understand that a subscription = is considered that same as a standby, in this context?

<= div class=3D"gmail_quote">
On Wed, Jun= 5, 2024 at 12:55=E2=80=AFAM Koen De Groote <kdg.dev@gmail.com> wrote:
I recently read the entire= documentation on logical replication, but am left with a question on the b= uildup of WAL


It is written: " When dropping a subscription, the remote host is not reachable. In that cas= e, disassociate the slot from the subscription using ALTER SUBSCRIPTI= ON 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."


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

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

This "cause disk to fill up" w= arning 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? Ev= en if the WAL isn't written to disk by an "archive_command"?<= /div>

Regards,
Koen De Groote
--0000000000009df0d4061a1872dd--