| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | 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-07-12 20:26:00 |
| Message-ID: | CALj2ACV9YBChGHOimyyLd+_F94wbOSrNFh-6Qu0fyB6t0eGZ2Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Jul 9, 2026 at 2:53 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > I partially agree with your suggestion for case 2. My preference is to
> > not add any blockers for vacuum. It does opportunistic XID-age
> > invalidation, invalidates the slots it can take without waiting, and
> > leaves the held ones to the checkpointer, which is the guaranteed
> > path. It is also easier to reason about and to explain to users.
>
> > The tradeoff is that vacuum won't invalidate a held slot in the same
> > pass, so the relation being vacuumed right then doesn't get the
> > advanced horizon. Once the checkpointer has invalidated the slot,
> > later relations pick it up, which may well be in the same vacuum cycle
> > or next. I am fine with that.
>
> > I would skip having the vacuum explicitly wake the checkpointer when
> > it sees a held slot. Imagine one walsender holding the slot's xmin and
> > 8 autovacuum workers running. Each worker hits that same held slot and
> > would signal the checkpointer, so we would get a signal per worker for
> > a single slot, repeated every cycle until the checkpointer acts. If
> > the checkpointer is already running, another request gets queued, and
> > this can happen repeatedly, creating a flood of checkpoint requests.
>
> I agree that we should avoid requesting checkpoints just to invalidate
> XID-aged slots.
>
> If we rely on the checkpointer for held slot cases, XID-aged slots
> held by someone could be left for up to one day, the maximum value of
> checkpoint_timeout, in the worst case.
>
> Given that it's not common for XID-aged slots to
> be still held by someone, it would be okay to skip the held slots. The
> same applies on replicas, where the restartpoint pass is the only
> mechanism anway. So I agree to simply skip held slots.
Thank you! Please find the attached v12 patch with this change. I
dropped the 0002 patch that was pushing the tests to reach a
production-like XID wraparound since it takes a bit of time to run
such tests and I understand that our test infrastructure and resources
are not free. I folded the tests into simpler ones in 0001 itself.
Tests now cover vacuum, autovacuum invalidating unheld slots, skipping
held slots, checkpoint and restartpoint doing the invalidation, and
both logical and physical replication slots. I believe this gives good
coverage for the feature.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v12-0001-Introduce-max_slot_xid_age-to-invalidate-old-rep.patch | application/x-patch | 40.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-07-12 20:47:02 | Re: pg_hosts: Add pg_hosts_file_rules() |
| Previous Message | Sivaprasad | 2026-07-12 20:11:21 | Let ILIKE utilize existing lower() expression indexes |