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 1w5iB0-003Xz2-1M for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2026 10:42:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5iAy-002D3d-2v for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2026 10:42:57 +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 1w5iAy-002D3U-1t for pgsql-hackers@lists.postgresql.org; Thu, 26 Mar 2026 10:42:57 +0000 Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w5iAw-00000001Grv-22gW for pgsql-hackers@postgresql.org; Thu, 26 Mar 2026 10:42:56 +0000 Received: by mail-vk1-xa2d.google.com with SMTP id 71dfb90a1353d-5637886c92aso425107e0c.0 for ; Thu, 26 Mar 2026 03:42:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774521773; cv=none; d=google.com; s=arc-20240605; b=c9FhP0mCURFU2PcuZgPnf8uOasZUpN99CMl5eV7xoIG2uWqLRScasGCpv4uneH/VcS 5C84y7UKcpHw68cj7/Nrjs4ylEOkvzW2Ri+BKErLarxJ6TWgaqfvxwtbGXZa82F/YEcA iShC5mYqhtE4HgLqNqn/EQyCiEfkzhTYNNkzr5rdFYAJxGIrQjOThDL4cUFUMkSpdD0D TViVbnrj1nZTYQmqc68ML7O5/Z52I7JhcRjoI9FvLKLEkvmr+j0RN4IPxCcOORtxh611 RjcDy1rXQ7MJi9+vK6krIce9ZD0l/GXuPVcM1L3EouaoORZK8Pus2TaH24Z7OuVJRL/a wiqg== 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=1H3hPEMXN/g1ysWWH45dshG3djLdincQsf7GEKegl0U=; fh=XzP9d9Yg0jEwXzsN1Fv+sAfqg5EJbsNT8RizoxPvDRM=; b=AcR84zqVCCgGjcsXprNpxl2gHLF5ktYukXnfYUnLXnA8pMYATCECAwpaOefjZ/tdDM iweRbLcg/i3fNOFx1Ej1ggXGANymkizSE9tH0d8M2T5U2MLjimE8PihrWOZhVXtIimfn paufCfDtqIvhSI9jKiBYv7mHM1AYiHUFnZT85aF8gdAtdkNDpUsImPtDX90hW5fIFebM xXAbokvvglLQCOFN9kpu9jc96Rb4CzAFYgu1GtsimZu9nqZ9qoPFsM9N1TH0TyLguOtR 0H8aolp5m5E/UkyiceawjzjqZy7QTjbQMkIK/fdCwCgU79bEN9vKHbVoS8r5Tmwx2nQC Rq8Q==; 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=1774521773; x=1775126573; 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=1H3hPEMXN/g1ysWWH45dshG3djLdincQsf7GEKegl0U=; b=BfIlMKGPxsEMsbxQoBoqt2W/tyAHguX3YkuXrx+mlaBbEaFkXslkdEn7URiQ21i3yB ZiGU1idxJJzoPLOTkk4mLaMl9znusmNZYWdBjvNv/lZSTgAi7jH6VTZjgH1yWjSsWCju 68KWYRYk0iFD1aza/DvBtfNf6q87DjxIvod8yTBtrYiG8aZEdQabTQlI06Pe8xmXcuhg lUQmOkp6LWKbos7SGLsVld1mSQx0tpcYsnlD/F1kAUJlzwTfX3vkxDp3+av6qwShwwIR 6OJqvoGOTwlNARgHnn5IihruTIoVm5k/Q+bta3L206YFLZJ54Ta/8ChSJXzXGjgQrRtd 0tqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774521773; x=1775126573; 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=1H3hPEMXN/g1ysWWH45dshG3djLdincQsf7GEKegl0U=; b=CKsjuKeXcuSAbp1MZOcaZyxf/kxief05cBGgGQS2OnXIbGQRcny4oQA33vDUq+ysCL z//rGrHGyhFtmlsdT/XxEre1UJp2pRoYKfnkLOasqa0sDE3NXvUUR2ipa23fIeoIGMXi twx98dM6toeyzyLcszi3V/lHZpxhPe953V4Oajmv6DUTQHjoxY8l+RJLEpKVoCvx3smo pa49WWi6loOVPDz77L5UO6Vj+LFNH4fit0qQTpV5pRba3HPZERlk3FzqaxNkCNXhbsqS Ylsp1WXmeIGa01DJDXzhsppebe3QvYfDaKPyaKonrk4rXo0qKaMyeopS42Au5PmI8t6l IpsQ== X-Forwarded-Encrypted: i=1; AJvYcCXb1m46gopI5Cj9C5Ao6vXFwhNk47uwKznRZhvLAW0nmvg5X4VkUL+0WyxxXva96I0IieVLsDq2ExO11dsW@postgresql.org X-Gm-Message-State: AOJu0YwPj+QB0PQNqOSmOAkeNvfLwomKZzq+owJ7CQzUDVkR6BgYW01C +nVo/VQML27SCvI71+3dwBaHpsVhHJgMGYbvLCFX9iqQA/PSewYMhetxGFA9b2YQJKgHZ8ZkycQ QX2lEb4CKOxcEpPtuXOIqmMVdzHdqvNA= X-Gm-Gg: ATEYQzwHUIHRl1MWkQ/8JR+tjnmia+QIz/N9B69niZBvSoKULd2GWDmaLDbcSQFmLyk 4hrO5wzWdAQelNkLCjsVipw+ppWp8kT5HLDQGn+qBcrxGl2XuUYhLKC3ieC3Ypo0dOsllfjurTh OQyzuzGTlF+EA2Ua06Yh+28Lr2noWxR8q90/BabXLRxdp4dlsGjQnaGKLfKfmrubgTybsU19m/k twCQHj1bInWrjSovxH5S1N+XeLKxFvcL2284CwHCUG9ntRBtHMUE/4NW7encTWMKjb6sm4GjHbZ XhsrSn8= X-Received: by 2002:a05:6122:1c09:b0:56c:c71a:e09a with SMTP id 71dfb90a1353d-56d220f11aamr3191491e0c.14.1774521773361; Thu, 26 Mar 2026 03:42:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: SATYANARAYANA NARLAPURAM Date: Thu, 26 Mar 2026 03:42:42 -0700 X-Gm-Features: AQROBzCFjmoStDsmonTOuXhq5Mxd5YldsiDcRyOSsCHNsEWrX_JeE9okUxHcz3o Message-ID: Subject: Re: Introduce XID age based replication slot invalidation To: Bharath Rupireddy Cc: Masahiko Sawada , "Hayato Kuroda (Fujitsu)" , John H , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000f28dfe064deb0bc9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f28dfe064deb0bc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 25, 2026 at 12:17=E2=80=AFPM Bharath Rupireddy < bharath.rupireddyforpostgres@gmail.com> wrote: > Hi, > > On Tue, Mar 24, 2026 at 11:50=E2=80=AFPM Masahiko Sawada > wrote: > > > > > Please find the v3 patch for further review. > > > > Thank you for updating the patch. I think the patch is reasonably > > simple and can avoid unnecessary overheads well due to XID-based > > checks. Here are some comments: > > Thank you for reviewing the patch. > > > vacuum_get_cutoff() is also called by VACUUM FULL, CLUSTER, and > > REPACK. I'm not sure that users would expect the slot invalidation > > also in these commands. I think it's better to leave > > vacuum_get_cutoff() a pure cutoff computation function and we can try > > to invalidate slots in heap_vacuum_rel(). It requires additional > > ReadNextTransactionId() but we can live with it, or we can make > > vacuum_get_cutoffs() return the nextXID as well (stored in *cutoffs). > > +1. I chose to perform the slot invalidation in heap_vacuum_rel by > getting the next txn ID and calling vacuum_get_cutoffs again when a > slot gets invalidated. IMHO, this is simple than adding a flag and do > the invalidation selectively in vacuum_get_cutoffs. > > > if (TransactionIdPrecedes(oldestXmin, cutoffXID)) > > + { > > + invalidated =3D > InvalidateObsoleteReplicationSlots(RS_INVAL_XID_AGE, > > + 0, > > + InvalidOid, > > + > InvalidTransactionId, > > + nextXID); > > + } > > > > I think it's better to check the procArray->replication_slot_xmin and > > procArray->replication_slot_catalog_xmin before iterating over each > > slot. Otherwise, we would end up checking every slot even when a long > > running transaction holds the oldestxmin back. > > +1. Changed. > > > + if (!TransactionIdIsNormal(cutoffXID)) > > + cutoffXID =3D FirstNormalTransactionId; > > > > These codes have the same comment but are doing a slightly different > > thing. I guess the latter is missing '-'? > > Fixed the typo. > > I fixed a test error being reported in CI. > > Please find the attached v4 patch for further review. > + if (InvalidateXIDAgedReplicationSlots(vacrel->cutoffs.OldestXmin, + ReadNextTransactionId())) Does this account catalog xmin for data tables? Thanks, Satya --000000000000f28dfe064deb0bc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, Mar 25, = 2026 at 12:17=E2=80=AFPM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>= ; wrote:
Hi,

On Tue, Mar 24, 2026 at 11:50=E2=80=AFPM Masahiko Sawada <sawada.mshk@gmail.com> = wrote:
>
> > Please find the v3 patch for further review.
>
> Thank you for updating the patch. I think the patch is reasonably
> simple and can avoid unnecessary overheads well due to XID-based
> checks. Here are some comments:

Thank you for reviewing the patch.

> vacuum_get_cutoff() is also called by VACUUM FULL, CLUSTER, and
> REPACK. I'm not sure that users would expect the slot invalidation=
> also in these commands. I think it's better to leave
> vacuum_get_cutoff() a pure cutoff computation function and we can try<= br> > to invalidate slots in heap_vacuum_rel(). It requires additional
> ReadNextTransactionId() but we can live with it, or we can make
> vacuum_get_cutoffs() return the nextXID as well (stored in *cutoffs).<= br>
+1. I chose to perform the slot invalidation in heap_vacuum_rel by
getting the next txn ID and calling vacuum_get_cutoffs again when a
slot gets invalidated. IMHO, this is simple than adding a flag and do
the invalidation selectively in vacuum_get_cutoffs.

>=C2=A0 =C2=A0if (TransactionIdPrecedes(oldestXmin, cutoffXID))
> +=C2=A0 =C2=A0{
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidated =3D InvalidateObsoleteReplicat= ionSlots(RS_INVAL_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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,
> +=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 InvalidOid,
> +=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 InvalidTransactionId,<= br> > +=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 nextXID);
> +=C2=A0 =C2=A0}
>
> I think it's better to check the procArray->replication_slot_xm= in and
> procArray->replication_slot_catalog_xmin before iterating over each=
> slot. Otherwise, we would end up checking every slot even when a long<= br> > running transaction holds the oldestxmin back.

+1. Changed.

> +=C2=A0 =C2=A0if (!TransactionIdIsNormal(cutoffXID))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cutoffXID =3D FirstNormalTransactionId; >
> These codes have the same comment but are doing a slightly different > thing. I guess the latter is missing '-'?

Fixed the typo.

I fixed a test error being reported in CI.

Please find the attached v4 patch for further review.
=
+ if (InvalidateXIDAgedReplicationSlots(vacrel->cutoffs.O= ldestXmin,
+ =C2=A0ReadNextTransactionId()))

Does this account catalog xmin for data tables?

Thanks,
Satya
--000000000000f28dfe064deb0bc9--