Hi all, On Thu, Feb 19, 2026 at 5:18 PM jian he <[email protected]> wrote: > > On Thu, Jul 31, 2025 at 2:24 AM Corey Huinker <[email protected]> wrote: > > > >> > >> Besides, this does nothing you haven't been able to do for > >> decades with expression indexes. > > > > > > What I'm hoping for with this feature is a smoother transition when people > > start introducing virtual columns. If there was already an index on that > > expression, and some queries start using the new virtual column (with the > > same expression), will that cause those queries to miss the index we > > already have? If it doesn't, then a customer can roll out the query changes > > at will and not need to do some cut-over from using the expression to using > > the virtual column. > > > > hi. > I am not sure whether this concern has been addressed, as I am still somewhat > confused by the above paragraph. > > As noted earlier, creating an index on a virtual generated column results in a > new index, and that index behaves the same as a regular expression index. > > An updated and polished patch is attached. The regress tests are quite verbose > at the moment, since I make it covered all index types (btree, gist, spgist, > hash, gin, and brin). >
I went through the discussions and have reviewed the patch. During testing, I encountered a segmentation fault during initdb which occurred due to a crash in bootstrap mode when ComputeIndexAttrs() was invoked with pstate == NULL while system catalog indexes were being created. The virtual generated column handling logic was executing unconditionally, which is unsafe during bootstrap because catalog and syscache state are not fully initialized. I fixed this by guarding the virtual generated column logic to skip the logic when IsBootstrapProcessingMode() is true so that it can prevent the generated-column rewrite from executing during bootstrap. After the fix, initdb no longer crashes in bootstrap mode, the full regression test suite passes cleanly, the server starts normally and key behaviors like index creation on virtual generated columns, planner rewrite, dependency tracking, partitioned table support, and dump/restore roundtrips are all correct. Also I performed some additional validations to ensure consistent behaviours. With the bootstrap guard in place, the patch seems functionally correct, catalog-safe, and dump/restore safe. Kindly review the patch. Looking forward to more feedback. Regards, Soumya
From 1d8378ed05e35c303a1ad8120a59bca8a1157554 Mon Sep 17 00:00:00 2001 From: Soumya <[email protected]> Date: Fri, 27 Feb 2026 16:00:05 +0530 Subject: [PATCH] skip virtual generated column handling during bootstrap Signed-off-by: Soumya <[email protected]> --- src/backend/commands/indexcmds.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c index 7579afffcc9..7875e178aea 100644 --- a/src/backend/commands/indexcmds.c +++ b/src/backend/commands/indexcmds.c @@ -1991,7 +1991,9 @@ ComputeIndexAttrs(ParseState *pstate, * indexes. We therefore collect the virtual generated columns attribute * number for subsequent verification of expression attributes. */ - if (reltupldesc->constr && reltupldesc->constr->has_generated_virtual) + if (!IsBootstrapProcessingMode() && + reltupldesc->constr && + reltupldesc->constr->has_generated_virtual) { for (int i = 0; i < reltupldesc->natts; i++) { -- 2.34.1
