| From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| 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-05-12 10:30:11 |
| Message-ID: | 20260512193011.1475adccc7ecc8961bafaeda@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 3 May 2026 11:04:59 -0700
SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> wrote:
Thank you for updating the patch!
There are a few comments on v2 patch.
In compute_expr_stats(),
+ PG_CATCH();
+ {
+ ExecDropSingleTupleTableSlot(slot);
+ FreeExecutorState(estate);
+ PG_RE_THROW();
}
Should we switch the context to expr_context before releasing
slot and estate? Also, should we call MemoryContextDelete(expr_context)
to release palloc'ed memory in the loop?
(In fact, the error would not be cached in compute_expr_stats(), though,
since it would be cached in make_build_data() if any.)
Should we switch to expr_context before releasing slot and estate?
Also, should we call MemoryContextDelete(expr_context) to release
memory allocated by palloc() in the loop?
(In practice, errors would not catched in compute_expr_stats() itself,
since they would already be caught in make_build_data() if any.)
+ /*
+ * Wrap expression evaluation and stats computation in PG_TRY so
+ * that errors from evaluating expressions (e.g. division by zero
+ * in virtual generated columns) don't cause ANALYZE to fail
+ * entirely. Skip the statistics object and issue a WARNING
+ * instead.
How about rewriting the comments to reflect the more general case?
Extended statistics involving virtual generated columns are a somewhat
special case, while errors in expression statistics seem more common
in practice. The same applies to the commit message as well.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-05-12 10:56:29 | Re: pg_createsubscriber: Fix incorrect handling of cleanup flags |
| Previous Message | Henson Choi | 2026-05-12 10:28:02 | Re: [SQL/PGQ] Early pruning for GRAPH_TABLE path generation |