MIME-Version: 1.0
References: <18876-0d0b53bad5a1f4c1@postgresql.org>
 <CAHGQGwFKngUKWOM=N3sAOGCL95TjQf2jM8E3put7=cmGKHHg0A@mail.gmail.com>
 <20260611132910.50412ffa57bbc8e70bad8fc3@sraoss.co.jp>
 <CAHGQGwGhDDF-KD72mHKR_Dvh6gfTV3i0q3+hY69MTXOxdOCo0g@mail.gmail.com>
 <CAHGQGwG+a=VADnPvxk-uMs0-XstgihC+rZzW1UJV6qECVZf+NQ@mail.gmail.com>
 <CA+TgmoY=5XoygpFxzO3DLjde9VS_jLYDEC=x7ZShd=LKkDysjw@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoY=5XoygpFxzO3DLjde9VS_jLYDEC=x7ZShd=LKkDysjw@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Tue, 7 Jul 2026 08:22:50 +0900
Message-ID: 
 <CAHGQGwEpG-9rsLZyqo49rcNDXAGjpL3LaiGc_iLYd4dTax+JAQ@mail.gmail.com>
Subject: Re: BUG #18876: HINT messages for mxid wrap-around say "drop stale
 slots", but that may not be appropriate
To: Robert Haas <robertmhaas@gmail.com>
Cc: TAKATSUKA Haruka <harukat@sraoss.co.jp>, pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwEpG-9rsLZyqo49rcNDXAGjpL3LaiGc_iLYd4dTax%2BJAQ%40mail.gmail.com>
Precedence: bulk

On Tue, Jul 7, 2026 at 2:23=E2=80=AFAM Robert Haas <robertmhaas@gmail.com> =
wrote:
>
> On Thu, Jul 2, 2026 at 10:26=E2=80=AFPM Fujii Masao <masao.fujii@gmail.co=
m> wrote:
> > I've pushed the patch. Thanks!
>
> Hi,
>
> I'm a bit concerned about this patch, specifically this part:
>
> +      <simpara>Unlike transaction ID wraparound, replication slots do no=
t
> +       directly hold back multixact cleanup. Dropping stale replication
> +       slots is therefore not usually relevant to resolving multixact ID
> +       wraparound problems.</simpara>
>
> The problem with the word "usually" here is that it leaves room for
> replication slots to be relevant in some corner case that isn't
> described, while asserting without explanation that they most often
> won't matter. I feel like that leaves users and DBAs in a very awkward
> position. The way it seems to me, either holding back the XID
> threshold can indirectly hold back the MXID threshold, or it can't. If
> it can, then the documentation before this patch was correct, and this
> shouldn't have been committed, and if it can't, then we don't need the
> word "usually" here.
>
> Now maybe that's a bit too simplistic. I'd be OK with a statement
> involving "usually" if it went on to explain convincingly why it
> doesn't normally happen and why it sometimes can under extraordinary
> circumstances. But without that, I feel this is making things less
> clear rather than more clear.

As far as I understand, there is no case where replication slots hold back
MXID cleanup. But I added "usually" only as a cautious wording choice.

If that my understanding is correct, I would like to update the docs to
remove "usually". Also, since "directly" in the same sentence might
cause similar confusion, it may be better to remove that as well.
So I am thinking of changing the text to something like this:

    Unlike transaction ID wraparound, replication slots do not hold back
    multixact cleanup. Dropping stale replication slots is therefore not
    relevant to resolving multixact ID wraparound problems.

Thoughts?

--=20
Fujii Masao