| 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
| 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 |