public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: another autovacuum scheduling thread
Date: Thu, 9 Oct 2025 12:15:31 -0400
Message-ID: <o33hdbfnosn7pw5e3a34jdtfoaxih6vwbe6rf7bo6ocbn4zv4l@incbnjupgq4o> (raw)
In-Reply-To: <aOfcTD3T7F3dydg8@nathan>
References: <aOaAuXREwnPZVISO@nathan>
	<l7k5nkow2n4x2lodcjimxl4wqv7rdjduo3zuzjwlx3kjxty5q2@gzl4pqbm6ows>
	<aOfcTD3T7F3dydg8@nathan>

Hi,

On 2025-10-09 11:01:16 -0500, Nathan Bossart wrote:
> On Wed, Oct 08, 2025 at 01:37:22PM -0400, Andres Freund wrote:
> > On 2025-10-08 10:18:17 -0500, Nathan Bossart wrote:
> >> The attached patch works by storing the maximum of the XID age and the MXID
> >> age in the list with the OIDs and sorting it prior to processing.
> > 
> > I think it may be worth trying to avoid reliably using the same order -
> > otherwise e.g. a corrupt index on the first scheduled table can cause
> > autovacuum to reliably fail on the same relation, never allowing it to
> > progress past that point.
> 
> Hm.  What if we kept a short array of "failed" tables in shared memory?

I've thought about having that as part of pgstats...


> Each worker would consult this table before processing.  If the table is
> there, it would remove it from the shared table and skip processing it.
> Then the next worker would try processing the table again.
> 
> I also wonder how hard it would be to gracefully catch the error and let
> the worker continue with the rest of its list...

The main set of cases I've seen are when workers get hung up permanently in
corrupt indexes. There never is actually an error, the autovacuums just get
terminated as part of whatever independent reason there is to restart. The
problem with that is that you'll never actually have vacuum fail...

Greetings,

Andres Freund

view thread (143+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: another autovacuum scheduling thread
  In-Reply-To: <o33hdbfnosn7pw5e3a34jdtfoaxih6vwbe6rf7bo6ocbn4zv4l@incbnjupgq4o>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox