Re: Bug: Whole-row var in indexes corrupts indexes after DDL

From: Matthias van de Meent <boekewurm(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Bug: Whole-row var in indexes corrupts indexes after DDL
Date: 2026-08-31 13:36:28
Message-ID: CAEze2WjnEvCNB6ZRzcjGYvzTjLvTryLmyW=45QtEK_vbe1QZoA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 31 Aug 2026 at 14:39, Matthias van de Meent <boekewurm(at)gmail(dot)com> wrote:
>
> On Sun, 23 Aug 2026 at 13:26, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> > For the record, an AI-assisted grep over the Hackorum archive puts the
> > virtual generated-column case (a4639d64e2) mentioned in the opening
> > message into a longer sequence: a unique whole-row index becoming
> > inconsistent after DROP COLUMN in 2020 [1], hash_record() indexes after
> > ADD or DROP COLUMN in 2023 [2], the work on whole-row dependencies for
> > DROP COLUMN and ALTER TYPE [3], the virtual generated-column case [4],
> > and rebuilding whole-row CHECK constraints after SET EXPRESSION [5].
> > This seems like good evidence that the general dependency is worth
> > representing, rather than fixing each new manifestation separately.
>
> This evidence is exactly why I started this patch.

v2 had the fixes for the issues you reported that were new and
specific to this patch. v3 is identical to v2 apart from
CompilerWarning fixes.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

Attachment Content-Type Size
v3-0001-Track-whole-row-Var-dependencies-in-pg_depend.patch application/octet-stream 22.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Tiwari 2026-08-31 13:38:03 Re: PG19 FK fast path: OOB write and missed FK checks during batched
Previous Message Matthias van de Meent 2026-08-31 13:29:32 Re: SQL-level pg_datum_image_equal