| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | TAKATSUKA Haruka <harukat(at)sraoss(dot)co(dot)jp>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18876: HINT messages for mxid wrap-around say "drop stale slots", but that may not be appropriate |
| Date: | 2026-07-06 17:22:48 |
| Message-ID: | CA+TgmoY=5XoygpFxzO3DLjde9VS_jLYDEC=x7ZShd=LKkDysjw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Jul 2, 2026 at 10:26 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)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.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-07-06 18:00:01 | Re: BUG #19519: REPACK can fail due to missing chunk for toast value |
| Previous Message | Ayush Tiwari | 2026-07-06 17:01:43 | Re: BUG #19544: PostgreSQL 18.3 backend crashes with SIGSEGV when a PL/pgSQL function |