Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3WQg-00054h-AM for pgsql-admin@arkaria.postgresql.org; Tue, 21 Jun 2022 05:27:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o3WQe-0006S9-Uz for pgsql-admin@arkaria.postgresql.org; Tue, 21 Jun 2022 05:27:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3WQe-0006Rz-Ii for pgsql-admin@lists.postgresql.org; Tue, 21 Jun 2022 05:27:56 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o3WQW-00019e-Vt for pgsql-admin@lists.postgresql.org; Tue, 21 Jun 2022 05:27:55 +0000 Received: by mail-pl1-x62c.google.com with SMTP id f8so11538780plo.9 for ; Mon, 20 Jun 2022 22:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=V0JX+Fj/4OcS4xH52Qgl6eAbqkjcUQW4JnsPGuZVhqo=; b=XcIso7fQwGJQIW6AuTyzygcO4yZZy9hcOOJCh/H/VGTUKzFLmPBE1tAHHWeAeDg7Nv o+FX+K4e0T4ov6szOEhI+rByhlBt6AMf0bQSdV0jfopdUn3kkIPsg88HO4lqbN8ZrLDR JDKpI6SLX9N2Pr3dZOJyQnhNAUemP9ij2o9tekiGwWUG2+sC4h60FmCekbE1GSSiIkS3 LzFufpPcIlgObq3SrI5vNw2v1yPEgys+hLQC+8wekEcTmZ1M0KEk/79ssTRVSwSw09lC s6w3Nf4hZHQ8fBhH4cNx9EHhhZLupevxaci6iWhl7QcPKc3O+CHNjpSfq2V8PTpv9Ke2 cdxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=V0JX+Fj/4OcS4xH52Qgl6eAbqkjcUQW4JnsPGuZVhqo=; b=ENABEzihyj9/XmG4jhmzqnwkQkOMkS3H8i9Cya4fkFqFwlOpmSx0ZC3pEBAKtMPNVo ztju64QBMke8nymC3fUZTDO2EnU5BLeoY5yrTiQjETKI24wOMFqvgMaTBt6wJvTOfCbi gWJc0w3aSc1W2hpUFMwhrd9gmRPFVOZWNkgHI7/9BYj1zcQdvU6RZJzayaY8JHhoN+xj es5ixlqu7NKbYUSOUsrBm0qd6E4+P6ha/ASxH3s9ngGc/GA9Y1Kpit3FZH6RCd/tyxYV nf0kXBXYZDHCCjncWpoZPLpkTzgMq70jIM5LeL7JLPOU5WeYr8hg9W9A5rnxtmTzX+cV nv6Q== X-Gm-Message-State: AJIora9KdEN9NfgrKGdya3tegvHvBtP4K5vp1SRMP5uhiUu5bvHL/ftI JbvAUiyNTB56f2DAQvdN1vQzX/Rgzyc= X-Google-Smtp-Source: AGRyM1tpqfxlAtRRYZgy4hEIjdGEeQcruMkoYoIm7GL2MHMQn6GlgiyplksrHKYvMEU9VUXW5k1Ryg== X-Received: by 2002:a17:90a:1049:b0:1ec:a10e:4071 with SMTP id y9-20020a17090a104900b001eca10e4071mr11288799pjd.227.1655789267415; Mon, 20 Jun 2022 22:27:47 -0700 (PDT) Received: from smtpclient.apple (2603-8001-3e43-3464-6403-da7c-0bfc-4d5b.res6.spectrum.com. [2603:8001:3e43:3464:6403:da7c:bfc:4d5b]) by smtp.gmail.com with ESMTPSA id b14-20020a17090a8c8e00b001eab4b8383csm11561556pjo.5.2022.06.20.22.27.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jun 2022 22:27:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-52AC1D52-FD2A-4DA9-BF68-55CBA20258BC Content-Transfer-Encoding: 7bit From: Teja Jakkidi Mime-Version: 1.0 (1.0) Subject: Re: Inactive replication slots Date: Mon, 20 Jun 2022 22:27:46 -0700 Message-Id: References: Cc: Pgsql-admin In-Reply-To: To: Jeff Janes X-Mailer: iPhone Mail (19A404) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail-52AC1D52-FD2A-4DA9-BF68-55CBA20258BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jeff, You are correct. That is what was missing on replica servers. When I set tha= t parameter, slots were active automatically. Thank you. Regards, Teja. Thanks and Regards, J. Teja Sri. > On Jun 20, 2022, at 8:55 PM, Jeff Janes wrote: >=20 > =EF=BB=BF >> On Mon, Jun 20, 2022 at 3:12 PM Teja Jakkidi w= rote: >=20 >> Hello Everyone, >>=20 >> I have a primary Postgres server with 2 standbys setup using streaming re= plication. Both the stand by servers are using the replication slots. >> Today, when I checked the status of replication slots on primary, they ar= e showing active=3D =E2=80=98f=E2=80=99. The data is replicating with no iss= ues but when the slots are inactive I know that the wal files generated afte= r the restart_lsn will not be deleted and retains the transactions, which is= very critical. >> I am not sure exactly why the slots are inactive and if there is a way to= activate them back? >=20 > Is primary_slot_name set on each replica? >=20 > Cheers, >=20 > Jeff --Apple-Mail-52AC1D52-FD2A-4DA9-BF68-55CBA20258BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jeff,

You are correct= . That is what was missing on replica servers. When I set that parameter, sl= ots were active automatically. Thank you.

Regards,<= /div>
Teja.

Thanks and Regards,
J. Teja Sri.=

On Jun 20, 2022, a= t 8:55 PM, Jeff Janes <jeff.janes@gmail.com> wrote:

=EF=BB=BF
On Mon, Jun 20, 2022 at 3:12 PM Teja Jakkidi <teja.jakkidi05@gmail.com> wrote:
Hello Everyone,

I have a primary Postgres server with 2 standbys setup using streaming repli= cation. Both the stand by servers are using the replication slots.
Today, when I checked the status of replication slots on primary, they are s= howing active=3D =E2=80=98f=E2=80=99. The data is replicating with no issues= but when the slots are inactive I know that the wal files generated after t= he restart_lsn will not be deleted and retains the transactions, which is ve= ry critical.
I am not sure exactly why the slots are inactive and if there is a way to ac= tivate them back?

Is primary_slot_name s= et on each replica?

Cheers,

Jeff
= --Apple-Mail-52AC1D52-FD2A-4DA9-BF68-55CBA20258BC--