Re: Experimental patch for terminating VACUUM freeze blockers

Hi Sami

> My 2c. Using something like the proposed
> vacuum_freeze_terminate_blockers_pid (GUC name is misleading, since
> it's a bool )
> seems backwards to me. It does not address the root cause, which is
> the long-running
> transaction, etc and attempts to deal with the symptom rather than the
problem.
> This also means a poor configuration of this parameter will more
> likely lead to a system
> silently getting into wraparound, as a DBA may relax a bit on monitoring,
maybe.

Thanks for your comments. I agree that the real problem is the long-running
transaction or other blocker, and this patch is not meant to replace
monitoring or fixing that root cause. The idea was inspired by the
replay/query conflict mechanism. Normally we do not want to cancel
long-running queries that block replay either; alternatively, we can enable
hot_standby_feedback, but that brings other problems. So this is a
trade-off left to the DBA. I think this is similar: the right solution is
still to prevent xid wraparound by managing the blockers, but when the
system is already approaching wraparound, terminating blockers may be
preferable to letting the system continue toward a dangerous state. So this
is intended as a last-resort option, not as the primary solution.

> I do think we need better visibility into what is blocking vacuum, which
was
> discussed here [1], but ultimately it is up to the DBA to properly monitor
> and mitigate workloads that are impacting their vacuum.

> [1]
https://www.postgresql.org/message-id/flat/CAOzEurSgy-gDtwFmEbj5%2BR9PL0_G3qYB6nnzJtNStyuf87VSVg%40mail.gmail.com

I'm in this thread,I know you're good at adding relevant system views.
Often, checking system views is more convenient than looking at logs. If
this request is approved, I’d appreciate your help in implementing the
corresponding system views.
.

Thanks

On Thu, May 14, 2026 at 3:55 AM Sami Imseih <samimseih(at)gmail(dot)com> wrote:

> > On Wed, May 13, 2026 at 07:56:43PM +0800, wenhui qiu wrote:
> > > I have an experimental patch to explore handling this situation. The
> patch
> > > adds a GUC, vacuum_freeze_terminate_blockers_pid, which allows VACUUM
> to
> > > terminate regular client backends whose transaction horizon blocks
> VACUUM
> > > from advancing its freeze cutoff. The intended targets are
> > > idle-in-transaction sessions and long-running active transactions that
> are
> > > holding an old xmin or assigned XID.
> >
> > Thanks for sharing. I certainly agree that this area has room for
> > improvement in Postgres.
>
> My 2c. Using something like the proposed
> vacuum_freeze_terminate_blockers_pid (GUC name is misleading, since
> it's a bool )
> seems backwards to me. It does not address the root cause, which is
> the long-running
> transaction, etc and attempts to deal with the symptom rather than the
> problem.
> This also means a poor configuration of this parameter will more
> likely lead to a system
> silently getting into wraparound, as a DBA may relax a bit on monitoring,
> maybe.
>
> I do think we need better visibility into what is blocking vacuum, which
> was
> discussed here [1], but ultimately it is up to the DBA to properly monitor
> and mitigate workloads that are impacting their vacuum.
>
> [1]
> https://www.postgresql.org/message-id/flat/CAOzEurSgy-gDtwFmEbj5%2BR9PL0_G3qYB6nnzJtNStyuf87VSVg%40mail.gmail.com
>
> --
> Sami Imseih
> Amazon Web Services (AWS)
>