Re: Infinite Autovacuum loop caused by failing virtual generated column expression

From: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Infinite Autovacuum loop caused by failing virtual generated column expression
Date: 2026-04-14 07:16:42
Message-ID: CAHg+QDfu46gK5mqtG9fA5YnT+rc70nidPYs_TFsZk-z2bdTysQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

On Mon, Apr 13, 2026 at 11:24 PM Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:

> On Sat, 11 Apr 2026 17:33:13 +0100
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> > On Fri, 10 Apr 2026 at 21:19, SATYANARAYANA NARLAPURAM
> > <satyanarlapuram(at)gmail(dot)com> wrote:
> > >
> > > PG19 added support for stats on virtual generated columns [1].
> Creating extended statistics on a virtual generated column whose expression
> can raise an error leads to ANALYZE failing repeatedly, and autovacuum
> retrying indefinitely. This floods the server logs and also wastes
> resources. Vacuum analyze on that column (without extended stats) succeeds.
> > >
> >
> > True, though this is nothing new. The same thing can happen with
> > expression statistics on an expression that raises an error, which has
> > been possible since PG14.
>
> Yes, this issue is not new, and I’m not aware of a way to prevent it a
> priori.
>
> >
> > > In order to avoid retry storms, I think we have two options. (1)
> skipping the offending row from the sample, (2) skipping the extended stats
> computation for that table with a warning message. At least this avoid
> autovacuum infinite retry. Attached a draft patch for the option (2).
> Thoughts?
> > >
> >
> > I'm not sure. The default retry interval is 1 minute, so it won't
> > exactly be a flood of messages. Also, if the error only occurs for a
> > small subset of rows, it's possible that retrying might succeed.
>
> I think it would be good to skip ANALYZE for the extended statistics that
> cause
> errors and just emit a warning, rather than aborting ANALYZE for the
> entire table.
> It seems reasonable to treat this as the user’s responsibility to notice
> the warning
> and address the underlying issue.
>

Yugo, thanks for the comments. Could you please review the v1 patch when you
get a chance. It is in the direction you suggested.

Thanks,
Satya

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-04-14 07:32:31 Re: Support EXCEPT for TABLES IN SCHEMA publications
Previous Message Evgeny Voropaev 2026-04-14 07:08:24 Re: Compress prune/freeze records with Delta Frame of Reference algorithm