Thread

Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column

jian he <jian.universality@gmail.com> — 2026-05-07T01:14:47Z

On Thu, May 7, 2026 at 1:13 AM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
>
> Sorry, I didn't have injection_points enabled, but now I see it too.
> The attached v9 fixes it.
>

diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index 1eb6b9f1f40..363830f0158 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -1408,6 +1408,7 @@ Bitmapset *
 ExecGetUpdatedCols(ResultRelInfo *relinfo, EState *estate)
 {
  RTEPermissionInfo *perminfo = GetResultRTEPermissionInfo(relinfo, estate);
+ Bitmapset *updatedCols = perminfo->updatedCols;

  if (perminfo == NULL)

----------------------------------------------------
v8 crashes because in some cases, `perminfo` is NULL and we are
``perminfo->updatedCols;``

        /*
         * If we don't have a ForPortionOfState yet, we must be a partition
         * child being hit for the first time. Make a copy from the root, with
         * our own TupleTableSlot. We do this lazily so that we don't pay the
         * price of unused partitions.
         */
        if ((((ModifyTable *) context.mtstate->ps.plan)->forPortionOf) &&
            !resultRelInfo->ri_forPortionOf)
        {
            ExecInitForPortionOf(context.mtstate, estate, resultRelInfo);
        }

the comment "partition child" seems not 100% accurate.
Since we also need to consider table inheritance.
Maybe replace it with "child table".