Re: BUG #18244: Corruption in indexes involving whole-row expressions

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: nik(at)postgres(dot)ai, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18244: Corruption in indexes involving whole-row expressions
Date: 2023-12-13 01:38:23
Message-ID: CA+hUKGJPxjaD3d_qYrHPxHLS_=ktVMFK7O-+9RgTBzQUTB9q6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Dec 13, 2023 at 11:53 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Tue, 2023-12-12 at 19:28 +0000, PG Bug reporting form wrote:
> > nik=# create index on t1 (hash_record(t1));
> >
> > Such an index can easily be corrupted, e.g.:
> >
> > nik=# alter table t1 add column yo int default -1;
> >
> > Proposal: prohibit the use of whole-row expression – as it is already done
> > for generated columns and produce a similar error ("cannot use whole-row
> > variable in column generation expression")
>
> I reported that bug before:
> https://www.postgresql.org/message-id/flat/e48a5d9a2d3d72985d61ee254314f5f5f5444a55.camel%40cybertec.at

FTR I also posted a repro for another variation of that problem. I
think it's slightly more general that, it not just whole-row
expressions (eg index on <table_name>), it's row types generally:

https://www.postgresql.org/message-id/CA%2BhUKGKb4SB%2BqQ-vAVomxAvJY6um%2B5URyq2D0vv10g7mbYZ1Ww%40mail.gmail.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2023-12-13 01:40:53 Re: BUG #18238: Cross-partitition MERGE/UPDATE with delete-preventing trigger leads to incorrect memory access
Previous Message Kyotaro Horiguchi 2023-12-13 00:46:10 Re: BUG #18241: PushTransaction may cause Standby to execute ItemIdMarkDead