| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hans Buschmann <buschmann(at)nidsa(dot)net> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: AW: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx |
| Date: | 2023-10-24 15:56:17 |
| Message-ID: | 572494.1698162977@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hans Buschmann <buschmann(at)nidsa(dot)net> writes:
> 1st query: ERROR
> 2nd query to or_followup_archiv: Succeeds
> then 1st query repeated: SUCCEEDS!!
> With this direct update to or_followup_archiv (or an unclustered table) the error disappears.
Yeah. After more study I think there's less there than meets the
eye. If the row update manages to be HOT then we don't need to make
any new index entries so we never reach the troublesome code.
In your original reproducer, the CLUSTER step was important because
it left the target tuple in a fully-packed page with no room for a
HOT update on the same page. When playing around with variants or
even re-executing the same query, it matters how much free space
there is on the page containing the target tuple, and that is
affected by all sorts of seemingly-irrelevant actions.
Anyway, we do now have a simple and reliable reproducer, so we can
work on fixing this. Thanks again for the report!
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-10-24 19:07:44 | Re: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx |
| Previous Message | Tom Lane | 2023-10-24 14:48:52 | Re: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx |