| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, John H <johnhyvr(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Introduce XID age based replication slot invalidation |
| Date: | 2026-08-16 05:35:00 |
| Message-ID: | CALj2ACWTz5fKMPa0wNghRFdfPBzc+j3x+kcXSeCo+3twZmDdyg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Aug 13, 2026 at 9:40 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Wed, Aug 12, 2026 at 05:00:00PM -0700, Bharath Rupireddy wrote:
> > I believe this can happen in practice (as explained above). IMHO, XID
> > age based slot invalidation must invalidate the synced slot on the
> > standby
>
> Yeah, I agree. Keeping the exemption for idle_replication_slot_timeout but
> removing it from CanInvalidateXidAgedSlot() makes sense to me.
Thanks for providing thoughts. I will wait for some time for Amit or
others to provide thoughts if any.
> One nuance about 3/ though: the synced slot is current in that case and the
> stale catalog_xmin is stored on the primary's physical slot. Therefore, the check
> for aged synced slots would not address this case: the synced slot is not aged,
> so it would not be invalidated.
3/ Long HS feedback interval: the synced slot's catalog_xmin is
current but its new value isn't reported, so the physical slot on the
primary keeps the old catalog_xmin.
You are right that in 3/ the synced slot on the standby is not aged,
so XID age based invalidation won't happen for it. The lag in this
case is only until the next HS feedback message is sent, so the
standby reports the advanced catalog_xmin and the primary's xmin
horizon moves on its own. The cases that actually get stuck are 1/ and
2/, where the synced slot's catalog_xmin stays old, and those are the
ones the synced-slot invalidation is meant to catch.
Also, if XID age based invalidation is enabled on the primary, the
physical slot holding that stale catalog_xmin (which the standby sent
in the previous HS feedback message) would age out and get invalidated
on the primary too.
> Worth adding a test with an actual synced slot, including checking that its
> invalidation releases the feedback horizon on the primary?
Yes, I will do so. I will turn either one of the following (maybe test
2 for determinism) into a test by ensuring that the synced slot on the
standby gets XID-age invalidated while its corresponding failover slot
and physical slot on the primary don't get invalidated, and ensure
that vacuum on the system catalogs doesn't get blocked. Does this look
good?
1/ Slot sync worker stuck or erroring: the synced slot's catalog_xmin
is old and gets sent onto the physical slot on the primary via HS
feedback.
2/ Slot sync worker is off with rare/missing/forgotten manual syncs:
the synced slot's catalog_xmin is old and gets sent onto the physical
slot on the primary via HS feedback.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuya Kawata | 2026-08-16 06:14:05 | [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN |
| Previous Message | Shinya Kato | 2026-08-16 05:18:44 | psql \d+ shows "Replica Identity: ???" for REPLICA IDENTITY NOTHING |