AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx

From: Hans Buschmann <buschmann(at)nidsa(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx
Date: 2023-10-23 17:05:03
Message-ID: 3c9fe737f6aa4ae9b0dc19bffd97e106@nidsa.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


Hello all,

I finally managed to reproduce the bug on a demo database as shown below.

The file err_demo.sql shows all the steps to reproduce. The table creation is done with errdb_noerr_231008.sql (unchanged from last mail).

The clue is:

- you have an inherited table
- on the archiv part, you have only (one or more) brin indexes
- to reorder the tuples before moving to a new major version (with pg_dumpo/restore) the archiv part is clustered.
this requires to create a btree index, which is removed immediately after the cluster statement.

when all this has been done, a write access to the archiv-part of the table hierarchy causes the error.

A direct update access to or_followup_archiv clears the error (as shown in the final comment part of err_demo.sql).

To make the error reappear, you have to redo the 3 recluster steps.

PS: please apply the steps of err_demo.sql manually because it was not tested for full automation.

Hope this enables you to investigate the root cause of the error.

Hans Buschmann
________________________________

Attachment Content-Type Size
err_demo.sql application/octet-stream 3.2 KB
errdb_noerr_231008.sql application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jacob Champion 2023-10-23 18:21:30 Re: pg_dump needs SELECT privileges on irrelevant extension table
Previous Message Robert Haas 2023-10-23 15:06:42 Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows