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 1sut0z-00Ax81-Vb for pgsql-general@arkaria.postgresql.org; Sun, 29 Sep 2024 12:27:06 +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 1sut0x-0048wV-L6 for pgsql-general@arkaria.postgresql.org; Sun, 29 Sep 2024 12:27:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sut0x-0048wM-9h for pgsql-general@lists.postgresql.org; Sun, 29 Sep 2024 12:27:03 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sut0q-001d3u-QX for pgsql-general@lists.postgresql.org; Sun, 29 Sep 2024 12:27:02 +0000 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a8d2daa2262so401782866b.1 for ; Sun, 29 Sep 2024 05:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727612815; x=1728217615; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BDs2NGDqfmmVh8B6rohL5SN0HQsKVe/h3OxEzTCAgz4=; b=A4BUseEoGA4jpqXdeRgiuSvyRP/ZTnNB8hZ5rkRnjQnrS27uSM0RDKhmKmj/4gkxKl 7PsHEcfMqK5Y5xwjO+8doHD4GW6Vt/YAnhLCZjTLjMHMbSQ7zrTAzWtTaHqpFZXk+5SH lUKiPTDAnKRzKgmyR3RSWTxgbtfWl359+28TaiUbSAKa7WY/Dqm9ae2LKmas4FsVphOp 4cODUM+acIH5yYm1yGBtHQEDxhRZbCisVBSkyFqATlm4VzeqrLm2TZiNoTHZCoqfU3uP 9Fp1puZ4rhac2WzCsWlU3egkSgVMtMqoVUxLlPgB8L+/cJ8/12Yr4So3J728/Wz8eT/6 Na9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727612815; x=1728217615; h=cc: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=BDs2NGDqfmmVh8B6rohL5SN0HQsKVe/h3OxEzTCAgz4=; b=j6fDbhINICkI5I/iacCmxmIEY6S30sHhx/x62PCjBuFSS3dc3hCUm0Meyj9cCi8TWh c+i0rsIpF5V7z9FP/YjHdnaubN5Bdb5zrCMQM1OG1ml0V0uAVJ22GOwdhr6AIcaHnYxh bnFkK+Vve/MubIFmowTT0EG3b8S9wXqnNdSquy/BrOoI3TJe7R+XQ4Ws3X6EAWYWT9rB uyCY8cx5MdmEFGZreUEQOltLvAeDcxynToekTRQ/HPZWtdi2G4+xA6dxYbx550jcS2sE StdT6lEfA0biKcShzkYkG6YcrhLCeLj0BnIb1zIwA2rqJamxWZG56LOL7eiPzO1KV/oX 1qSw== X-Forwarded-Encrypted: i=1; AJvYcCUTjc2LkAa7jLpVwlCCa+jeF20/ohSLBD134bAoSgYdzyX7f7dAe/G2AQv7vdkccNDShxHiowrAWzo6Ot/D@lists.postgresql.org X-Gm-Message-State: AOJu0YwkJ14eVEnhCrb6NrwL1J7IW+LVO3q3asvOhsQ9NUoPGmHoFHyP uEHQWjN3WfIxHvKoVASKuQYtcn8x1OOrSIOyY51aIgdSbcs/6h1oIdCZx1r6cM5QJYtYPGjTrV9 +myQJEWlDIrGQ/xm3WY3mr7nXNG0= X-Google-Smtp-Source: AGHT+IHIjFEeumyNaMdaOnseog6k/QXFKdS5B4lzV6QnNpY2ARDc8sFuQ0FstqxSDfeZ4H6K22SkVoTWPT8bIV5hcWs= X-Received: by 2002:a17:907:7e8c:b0:a8d:2ab2:c9a0 with SMTP id a640c23a62f3a-a93c4aae066mr899478066b.53.1727612814850; Sun, 29 Sep 2024 05:26:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: GF Date: Sun, 29 Sep 2024 14:26:42 +0200 Message-ID: Subject: Re: Logical Replication Delay To: Ramakrishna m Cc: Greg Sabino Mullane , Justin , pgsql-general , ravisql09@gmail.com Content-Type: multipart/alternative; boundary="00000000000023842d0623413467" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000023842d0623413467 Content-Type: text/plain; charset="UTF-8" Hi Ram, 29 set 2024, 12:29 Ramakrishna m : *We are planning to set up logical replication from a standby to another > server. When the primary goes down, there is no issue as the standby > becomes the primary and the logical slots are already present. However, > when the standby goes down, these slots are not copied to the third node or > the primary by Patroni. Is there an option available to handle this > scenario? * > You could take a look at the pg_failover_slots extension ( https://www.enterprisedb.com/docs/pg_extensions/pg_failover_slots/), it is aimed exactly at cloning the slot information to a standby. Best, giovanni --00000000000023842d0623413467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ram,

=C2=A029 set 2024, 12:29 Ramakrishna m <ram.pgdb@gmail.com>:

We are planning= to set up logical replication from a standby to another server. When the p= rimary goes down, there is no issue as the standby becomes the primary and = the logical slots are already present. However, when the standby goes down,= these slots are not copied to the third node or the primary by Patroni. Is= there an option available to handle this scenario?=C2=A0
<= /div>

You could take a look at the pg_failover_slots extension (https:= //www.enterprisedb.com/docs/pg_extensions/pg_failover_slots/), it is ai= med exactly at cloning the slot information to a standby.

Best,
giovanni

=
--00000000000023842d0623413467--