Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyyVm-0006Af-CK for pgsql-admin@arkaria.postgresql.org; Wed, 27 Feb 2019 12:40:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gyyVk-0002nL-CS for pgsql-admin@arkaria.postgresql.org; Wed, 27 Feb 2019 12:40:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyyVj-0002nC-UA for pgsql-admin@lists.postgresql.org; Wed, 27 Feb 2019 12:40:32 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyyVh-0002Zm-4J for pgsql-admin@postgresql.org; Wed, 27 Feb 2019 12:40:30 +0000 Received: by mail-qt1-x842.google.com with SMTP id v10so18926226qtp.8 for ; Wed, 27 Feb 2019 04:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=llcJPtgPm5UC02lmQnlYYrUDweV8mvZj1ssN/2vwmQg=; b=l/SUOdIBwljDgnVG3FI1qSk5a4trW2O8EsS/pnYuLNys4gdSLihw/o3DUOVPqR1pO+ XdsUOxLYFtcbQXeYw3yeUBp9zLHpk27xP2Q8JSd95kcg31t5LI5kuxJhvAGLWYhCRiJa M+Nsy77oviFmZ+jczVhPAEBMDGWXmpB4gZrmjetwMPWAUXAZ98LexPmVck7iL2UF7a0S 9Pp9lOZhjje0FIs51rnEu4RDK3Y2BLsWu+k8Qn3JUx/tfc2W7zXx+H+0zKDcKftrN2DJ EKIgALAf2ZyZSdQ6iRjqse+uNoOkQuQD5BVfo8MBLjf3sLFDapeadC62O22Ui7v2vO02 SY0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=llcJPtgPm5UC02lmQnlYYrUDweV8mvZj1ssN/2vwmQg=; b=GeHlVQbXM7h8fWXveZBeeLBnIZaM9FlX2ko4Rp+oT0TyNT4HlOGY4MWEvwfOIUX4FV ju290iMaSUJbQhG4bL3VfbCEjMuReQwHEr6E0Bm1WIkZEPRwBsyItPYheL0pg+nReM9J jDyl6NWNdJr/oVVyaTov00Q5GytHkxRc1huBEEPw7OKHAg4bNWchqTScM/fgN+AwUBog WmaY/S+xJfIuTz3tE472Zqzf9nYdtjIn69pJbxjI0YUHHnZn/lTompxm9f/e+a4+S7wh geW2+MVLa2qOkuL2xFZO+vqTwBejtPPYAW58DbZlTPwmADDE3GA7zKs9wsFP+hEZkJpw Se3Q== X-Gm-Message-State: APjAAAWeCNq8lyHoH4wWDu58uXC3DVEDaRdEwWVKQfCnnZ6gWgV9VF9i /qOr5UeAT51RlRGBCPkpPvsgYhO1 X-Google-Smtp-Source: APXvYqzROEmJYrJ4yOhsmk8o0FabNjGmJXp9YYobmGVX7bdUR765Fp1inoh9YPuxtE1enubuagtVZA== X-Received: by 2002:a0c:bd15:: with SMTP id m21mr1680658qvg.246.1551271227980; Wed, 27 Feb 2019 04:40:27 -0800 (PST) Received: from ?IPv6:2600:1003:b001:b748:6c7e:1517:31e0:8653? ([2600:1003:b001:b748:6c7e:1517:31e0:8653]) by smtp.gmail.com with ESMTPSA id j34sm3112305qte.49.2019.02.27.04.40.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 04:40:27 -0800 (PST) From: John Scalia Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Wed, 27 Feb 2019 07:40:26 -0500 Subject: Logical replication and wal segment retention Message-Id: <695C083D-AFB5-431B-B022-ED442CE94794@gmail.com> To: pgsql-admin@postgresql.org X-Mailer: iPhone Mail (16D57) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello, folks, Yesterday, I had a small file system fill up, due to some logical replicatio= n testing we had been performing. We had been testing IBM=E2=80=99s IIDR sys= tem and apparently it had built a logical replication slot on my server. Whe= n the test was completed, nobody removed the slot, so WAL segments stopped b= eing dropped. Now I can understand the difficulty separating what physical v= ersus logical replication needs from the WAL segments, but as logical replic= ation is database specific not cluster wide, this behavior was a little unex= pected, since the WAL segments are cluster wide. Are WAL segments going to p= ile up whenever something drops a logical replication connection? I=E2=80=99= ve seen it, but it seems like this could be a bad thing. - Jay Sent from my iPhone=