On Tue, Jul 7, 2026 at 2:23 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Jul 2, 2026 at 10:26 PM Fujii Masao <masao.fujii@gmail.com> 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 not
> + 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?
--
Fujii Masao
