| 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 |
| 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 |