On Wed, 22 Jul 2026 at 18:15, Peter Eisentraut <[email protected]> wrote: > > On 15.07.26 17:44, Nathan Bossart wrote: > > [RMT hat] > > > > On Wed, Jul 08, 2026 at 08:15:54PM +0200, Peter Eisentraut wrote: > >> Committed with some code beautification editorialization. > > > > This is listed on the v19 open items wiki [0] as an "older bug affecting > > stable branches." Is there more work to do, or can this be moved to the > > "fixed issues" section? > > > > [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items > > This is a fix for new-in-PG19 functionality, so I think that > classification is wrong.
I think this addressed just one symptom of the issue where PostgreSQL doesn't track whole-row expressions as a relevant dependency type, and so fails (failed) to invalidate whole-row Var -dependent objects. Yes, it was a new facet of the issue, but the issue itself was not new in PG19: Every catalog object type that relies on pull_varattnos() to track which columns are referenced is going to hit this issue; and no current path (other than SET EXPRESSION now) causes indexes and constraints to get rebuilt when the whole-row var expression changes meaning. I'd also say that the way SET EXPRESSION fixes this is ... suboptimal. RememberWholeRowDependentForRebuilding considers *all* indexes and constraints on the relation for invalidation, rather than just the ones that contain whole-row Vars. In partitioned systems, that can mean touching a huge number of catalogs just to check that there are no relevant CHECK constraints nor expression indexes. See [0] for my patch that solves this in a more holistic approach, by explicitly tracking whole-row Vars, and using that tracking to find and only consider the whole-row Var -referencing objects in RememberWholeRowDependentForRebuilding. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com) [0]: https://postgr.es/m/CAEze2WjDaDyvztdXh3Cb2J=11cmvrp4nwaw0e6dbrka1t9w...@mail.gmail.com
