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.96) (envelope-from ) id 1w6wZ7-004o57-1r for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Mar 2026 20:16:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w6wZ3-00HGW0-2G for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Mar 2026 20:16:54 +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.96) (envelope-from ) id 1w6wZ1-00HGVk-2M for pgsql-hackers@lists.postgresql.org; Sun, 29 Mar 2026 20:16:53 +0000 Received: from mail-ua1-x92f.google.com ([2607:f8b0:4864:20::92f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w6wYz-00000001h66-1Rqi for pgsql-hackers@postgresql.org; Sun, 29 Mar 2026 20:16:50 +0000 Received: by mail-ua1-x92f.google.com with SMTP id a1e0cc1a2514c-953aacb9d78so286100241.2 for ; Sun, 29 Mar 2026 13:16:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774815407; cv=none; d=google.com; s=arc-20240605; b=ffasmiJ6+EHsoZ3ykXays623fu6eHcpIqLyccQU4k1ATQAGvB1lqhDYrKlu0PAyqk9 ZAeJxi6QsopEeV/aVaan8+LTysDzyG/SGevmKlgb/077AYTrcS0Ql7jZIJnnS4U35Ui8 zwUqzQ5c29al1gjCwn1C+6yvs0bbpmlO+8lyRVCTAno3//Oi5D+kh3BdXN6FUcdA8pRC 3PNmPbq+FZDiSN99B/IiKH7dPQ0XUkCzTDPs8mIAeqtfj7Fu/Zh02u9KoU3Gk49Lj7UL tgSlaFYGxANAX+X+n5r1yuXnn+P5aR+o7Xf7XtLxHp7zY0KzSrk132m1AwGtf26bhC8d cyWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=VS9Ms9ghrjcScYeQVPO10a77vSBNDq0PZ03m/YQ8B+s=; fh=ShHTyGOog0tzdILdJ71hyMvs6SkyNyBq8sONYftedSE=; b=bl59bakyXXyEXXWRjJN/G5ss5hoZi2CQE0uAZloup7Mjh8283THv6IoH1uvd/7Ti81 rFzLfLHdZrSptGUMJQTzZy3Vvj8jLOsY9d8B0xc/Nc0mWBIyG4XpNxXNXhmhIPdCMHsH jNTwofD1tUPV0Le/TP/a4jAFTpXKYesdlg/gPb2ZLfg593GxwKixMUTe27xKqeUZcWpg nzeIcDD+bXHnbD1EGgj9bCVZxO0x6W8XU5IMzr1aA84+5KG/aLskcA7wV4IUZdGrCnWr MzztQixlnnz9rXi0I4Eftu4edt4EsGUd5R8gx0gZwQSPkTSsTvns17JpzXCll9fTHVqK 7oVA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774815407; x=1775420207; darn=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=VS9Ms9ghrjcScYeQVPO10a77vSBNDq0PZ03m/YQ8B+s=; b=g4BnrieZOMU3OBO93VRx0zY3lk1XCQlmuJTVTEAEtrjBtUqe/xy3ww3FCBkb96eFQv 422wxNGR4O9Ue2RRrWr8b2RM4+z44AkuzX6+pW1+2tMJsu000JJfNNh9V0GAGAklhdL/ HalIIs37tceOjWErB7uLuEb9G9ntYvb/ziIfX5ex7Rj0NyjSFHNj/KYcDDNIFD/Ynwgg hFl1tkf4pdYzHtpbxYI/jBXZrR0RUbOBl7Iao7Fr0eCKErG3+8WUZGFb2UwHHpIOEZ6M /7myjbO9rfXM5mUD7BWu7s7czERn0LuRvZAgbuFIvgYQVrVjUgWqb9sBX0xid6Ow9MdW Eyxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774815407; x=1775420207; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VS9Ms9ghrjcScYeQVPO10a77vSBNDq0PZ03m/YQ8B+s=; b=LvtM6MILtjB6crQbW+WTniSFLDLNf1HiT1zvnNuL7cMjXUXjI2a7jViJTIKpJ1PEGm ihJhJn6w7R7X6LVM2sS1gzF5LtMZI9PUTKy7Z+KjMC7dDB3ZFpYqjunm+0XeKYEuRO48 bRN8QQ1W2h/2RrHqRv+vbDzEJ1DVpHGICKToPi8WxP5OvhdoT6Au/flNXkX9C7SUXMdE TkS7EDpnlGm4x1hNxT3yvORdp0DnNgfZdhLraFzTmCtGB8bU4RqCR44jDkXlz+KMhhIL ReqrC6cEn8MpEUPUJsedkxcw7JdP60yhNELa4KzrDx9vPm3qM3Ed2/7QrttN4lCJ8NbI 81AA== X-Forwarded-Encrypted: i=1; AJvYcCV9crDApIpjC2xQbzeOgv8L+kTcnzlQD0BeMVKtvj6kCAGdy+xAE92/GGr9ZolyurwXZsUC7GlrWJNdEfAY@postgresql.org X-Gm-Message-State: AOJu0YzF1p4E7V72ZSiRl7Ll6p5w/VLNxkG4oVSop3fBSBxSxltra7mn dKwhwFZzRFU7RtOFxb9ZtFhsYV8xrBgjYI1DIwkb7brXe4OF/itmA8ni8x0Id1b+CKXgb7yDwWD VMkk2nEnPyGzNogW7hTisBY7MDqOyWhg= X-Gm-Gg: ATEYQzw9Xi4UWriEX5Z3ETlE8XhHGRUnZW5+fm45OGCC+w1NJwRzdzmS9urjHF5FpYn jUY52iHZttfG7l+JqvV2QKRGMvS8S0RwTreLjrLdAHlL56JgtC9netGA6S/z8DlBlpPn8thnlNs yZyP43qMIyyE5UHHgkkB6XvfkUUFfqZrZM+pkp0HeWVdVFT1hPjCq57mNMJJ6KcaP13j4mYmpEA nxjvm28VCi8zrFJyId6ybJ42VSSbE0ky+9NFkaCPFxwwAKNTA9d2jaEkdR1qGPRv/u/IwC/xnx4 YV3yq/TC76P5ijIKLlCChsVrTWDMZP0SFsPvoe5bMEuoHHSXtlfDlNMRplKlpZsC3heG0qTwPU/ PIUwGsQEkQCNDCde33SgwS02eLLU= X-Received: by 2002:a05:6122:4b0d:b0:56c:d753:db14 with SMTP id 71dfb90a1353d-56d4a62ce0fmr3456940e0c.14.1774815407332; Sun, 29 Mar 2026 13:16:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Srinath Reddy Sadipiralla Date: Mon, 30 Mar 2026 01:46:36 +0530 X-Gm-Features: AQROBzDJZjfIBrGKnQ3Zpat4iRQg8bgk00XjwWauKeUwm-pheEHxEg6vkuxzyQs Message-ID: Subject: Re: Introduce XID age based replication slot invalidation To: Bharath Rupireddy Cc: Masahiko Sawada , SATYANARAYANA NARLAPURAM , "Hayato Kuroda (Fujitsu)" , John H , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000e560de064e2f69ee" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e560de064e2f69ee Content-Type: text/plain; charset="UTF-8" Hello, Thanks for the v5 patch set, I have reviewed and did initial testing on v5 patch set, and it LGTM, except these diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c index 286f0f46341..c2ff7e464f0 100644 --- a/src/backend/replication/slot.c +++ b/src/backend/replication/slot.c @@ -1849,7 +1849,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause, else { /* translator: %s is a GUC variable name */ - appendStringInfo(&err_detail, _("The slot's xmin %u is %d transactions old, which exceeds the configured \"%s\" value of %d."), + appendStringInfo(&err_detail, _("The slot's catalog_xmin %u is %d transactions old, which exceeds the configured \"%s\" value of %d."), catalog_xmin, (int32) (recentXid - catalog_xmin), "max_slot_xid_age", max_slot_xid_age); } while testing the active slot XID age invalidation (SIGTERM path) , i observed that slot got invalidated , walsender was killed because of SIGTERM , then starts the infinite-retry-cycle problem where walreceiver starts walsender and walsender will try to use an invalidated slot and dies, will think more on this. -- Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/ --000000000000e560de064e2f69ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for the v5 pa= tch set, I have reviewed=C2=A0and did initial testing on
v5 patch set, a= nd it LGTM, except these

diff --git a/src/backend/replication/slot.= c b/src/backend/replication/slot.c
index 286f0f46341..c2ff7e464f0 100644=
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/s= lot.c
@@ -1849,7 +1849,7 @@ ReportSlotInvalidation(ReplicationSlotInvali= dationCause cause,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* translator: %s is a GUC variable name */
= - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appendStringInf= o(&err_detail, _("The slot's xmin %u is %d transactions old, w= hich exceeds the configured \"%s\" value of %d."),
+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appendStringInfo(&a= mp;err_detail, _("The slot's catalog_xmin %u is %d transactions ol= d, which exceeds the configured \"%s\" value of %d."),
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0catalog_xmin, (int32) (recentXid - ca= talog_xmin), "max_slot_xid_age", max_slot_xid_age);
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

while testing the active slot XID age = invalidation (SIGTERM path) , i=C2=A0
observed that slot got invalidated= , walsender was killed because of
SIGTERM , then starts the infinite-re= try-cycle problem where
walreceiver starts walsender and walsender will = try to use an invalidated
slot and dies, will think=C2=A0more on this.

--
Thanks,
Srinath Reddy Sadipiralla
EDB:=C2=A0= https://www.enterprisedb.com/
--000000000000e560de064e2f69ee--