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 1w7cDV-005Wp5-37 for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 16:45:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7cDU-00BSzb-1H for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 16:45:24 +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.96) (envelope-from ) id 1w7cDU-00BSzR-0O for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 16:45:24 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7cDR-00000002CjX-1j0B for pgsql-hackers@postgresql.org; Tue, 31 Mar 2026 16:45:24 +0000 Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-7d9b1c57a4cso5127450a34.3 for ; Tue, 31 Mar 2026 09:45:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774975520; cv=none; d=google.com; s=arc-20240605; b=j/L9hC2bZg5TIxaY5cRZCxFi08zJdMgXnh0aLnXv4rqtId5oNnMhmbHKGkKbun4Izi 12H90a50avFjHxW5RzThwM0uGwngM7+MzR8EQ4nqJoM6zZ8HfLFgaXpOFvFhQsSH76/I 3nlOj3ebpsrTuOfeCvAuAUboFxYoQv3UpJiFtH4tlVs5ayoxbW2YjfGxtPLfyW8gSN8z oBsL+JU/P5vnqhcqtGO+knbL8mEuKM7gqPVHzpo37DA2yzrsH1n9BcMTAVPUQIWrB3Tk U+paKfZMIAFcArRnV3i/1UBC/LI/jZgCDRUjoaX/gNfAJkC5Tg+gGkZXwtBwa1pAXLYt KCPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ZxrL6UwTh+rkRjv5VD4Qr0ow4h7r+yadvhxldtEhk6A=; fh=j/mrK+pjJhv6K4QJE5MqtQoWM8/ThS1WzyoVjuo4pgk=; b=ljrbRWlp6hyglkS20Q9TMoPZnyVahh4qB4PjZKmyj5IcJFCRTZpZbU16omD51IWZuI jwZX9YUgSOT1fWbjB4APkr/5r13Tf5b5iY/yPUawZPVsmO1Y8ASciXQS/jDOTudftG3P a0EAMNdIcEvNI2uGJGj+NX/pt1gbX9W8iH/CxG27Buo+q6J5cUxam21zA9MV5mTgSgp7 xyesg/Zt3JTG4uOMbPGr3ZNZEOYRPbHnM5nDkZ5YDXLirGYhjOMKwFLo2oXbD52osEpL TT1SFIg26ucY9nPPaye94vq2W8o7NUSJOa3oVGnHFozCvw26Ik9L+UkFAClBbulIlW7w oMJA==; 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=1774975520; x=1775580320; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZxrL6UwTh+rkRjv5VD4Qr0ow4h7r+yadvhxldtEhk6A=; b=kJrhSKXtlTB0ru3HQT4h6nbb9APaNoUxioypcBqqOXGWOZwQkFZRTPE0FQKNizl3jK zKSRl7f9jxXl/X29r+hcKrk5dyWUw5PYd3npy8xYOOur3IClo8Q4AkcnIsESLFPe+DIZ PQaaEIVMKakkY1SyT2v0iPWeXBDrOSLVGNAYKUA4o58sInOBKwHYdCnO1fje5zasbi7R xpGxQ4unKQyg5GXjlWBCoy9JDc8V5VGpoTCYhir8x3pFJhobwQ/qenvkUAySHv+hORyp hVsgDUuDzjxdnTkZ3nTTlwJmAxWrpfozwdQqq1fUTELNLuNeqMe32Lr/ps/tHg4GR+fS XPpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774975520; x=1775580320; h=content-transfer-encoding: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=ZxrL6UwTh+rkRjv5VD4Qr0ow4h7r+yadvhxldtEhk6A=; b=se4xtya15Q6SfTGCezS9bLbYwRT/Iz2MkoBqeh0W/k8IhEADaEl9fHygxyPzEP//7Z ehgDw1N9JkYHWvmy74X9dU8hO1vys6eH6tEAB+ESd3o33Q46tN9t1NQwpJtY3CZy4yAp KGAHxEaKODp++QbqQu2+mApdVGSAkfFUpeQPZFW+6uAvgMmUt/ZOZJeNKr0xiGx0k/7s P/XU8aXOAuEunKX+ZmJPU6O+gwZOlmUlKjKbPzqhGmU+G0JpR/tejQMSd3US5QKEpmS+ cjgumLYFbiBtySBfHRpfS5Nsd6cTvitY5zJf2iBIxhxKq13JLDvM2/qv9xzWHUsAh84V d+xg== X-Forwarded-Encrypted: i=1; AJvYcCVjxAIPDzc56kAZ3bvIimM0tMA+Ja3Y/Fbcuq4uXohCQqCwJjXsapIuCc83q1r86eXl9HlY9+MM9LzRKxkm@postgresql.org X-Gm-Message-State: AOJu0YyGVFH/O5JN7POyMWx+e3Gt4Z5eXn5RiccJUplGizxSEmk6lpyK VClDAPOaReWMn1WEjIaRa/nGy/Q6RRpIVmJhmvdyJ/4bsRc5X2Ehs8w/9q85sg1OdmY6z4LRZ6W GR3tmQO0M6X6esm4Tu8bTfc4RRioY7xA= X-Gm-Gg: ATEYQzw4OQeFQGwwHY6dSbWOzrxVrttgI6WSANvADF+DUfcExIufNQr0Eeh+RptUYMg CNnZhP2U9RefXHLjRoXZRnABps2TK/mf6yXgchMWj3zdO7NoTlNHLa1x91yPUQ9NTZmj9rVeITt Mu3XddwWKNIvibX/UDugojYXN8A9zlYIyt7CFsplgpDVYDM8/k2p/C7gHfshYKkV5xPgTC9Kra6 VEIsutuJ1n2s2c7WUlmcjGnf1T4mA7D5OaerwAgjGYUxS3EnD4QRSkpVh5fq14rVCajQR44YpPw Ws2bA+gt4GcMOBOya4rln0WUXHBP81g5/WHDxBfwwibUWsWbl5k= X-Received: by 2002:a05:6820:81c1:b0:67e:294b:7246 with SMTP id 006d021491bc7-67e294b7338mr6604886eaf.14.1774975520169; Tue, 31 Mar 2026 09:45:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bharath Rupireddy Date: Tue, 31 Mar 2026 09:45:08 -0700 X-Gm-Features: AQROBzDlm5hUV1ZHQu7lnOi9qJXMqL03m5Qd09FTkSavx_Alxo4yQ8-yZPHxmQQ Message-ID: Subject: Re: Introduce XID age based replication slot invalidation To: "Hayato Kuroda (Fujitsu)" Cc: Srinath Reddy Sadipiralla , Masahiko Sawada , SATYANARAYANA NARLAPURAM , John H , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Tue, Mar 31, 2026 at 12:25=E2=80=AFAM Hayato Kuroda (Fujitsu) wrote: > > Dear Bharath, > > Thanks for re-working the project. Thank you for looking into this. > While seeing the old discussion, I found that Robert Haas was agaist the = XID-based > invalidation, because it's difficult to determine the cutoff age [1]. > Can you clarify your thought against the point? Are you focusing on solvi= ng the > wraparound issues, not for bloated instance issue? > The code may not be accepted unless we got his agreement. > > [1]: https://www.postgresql.org/message-id/CA+TgmoZTbaaEjSZUG1FL0mzxAdN3q= mXksO3O9_PZhEuXTkVnRQ@mail.gmail.com I summarized what others (Nathan, Robert, Amit, Alvaro, Bertrand) said about it here with my responses: https://www.postgresql.org/message-id/CALj2ACVY%2BFd5vC0VjW%3D5VDK9mmt-Y%2B= PDZxnBp8ngGAZc24Vv9g%40mail.gmail.com. Please have a look. A good setting for this in production scenarios is to set max_slot_xid_age to vacuum_failsafe_age (1.6B) or little less, so that autovacuum invalidates the slot before entering failsafe mode, unblocking datfrozenxid advancement and avoiding XID wraparound without manual VACUUM or downtime. I added a test for this in the 0002 patch. Please have a look. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com