Re: [PATCH] Fix vacuum_delay_point happening inside lock

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Kevin Rocker <me(at)kevinrocker(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Fix vacuum_delay_point happening inside lock
Date: 2026-08-24 09:20:10
Message-ID: D56AEDC0-7E03-4B44-9836-E6E679DDCAB4@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kevin,

v6 addresses my concerns. Thank you for running the full CI.

I would keep the fixes in 0001 together. They all restore the same
invariant, and the production report for hash strengthens the backpatch
case without making that particular move a separate kind of change. A
committer can choose a narrower set for a particular branch if
needed (especially wrt just comments change).

I would consider 0002 separately, though. Adding the Assert on HEAD is
useful, but backpatching the fixes does not necessarily mean that we
should risk extra buildfarm noise in all stable branches.

Two tiny commit message typos in 0001: "it's duration" should be "its
duration", and "vaccuum" should be "vacuum".

With these minor points, the patch set looks Ready for Committer to me.

Thank you!

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-08-24 09:32:15 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Bertrand Drouvot 2026-08-24 08:48:59 Re: pgstat: Flush some statistics within running transactions, take 2