Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hans Buschmann <buschmann@nidsa.net>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Geoghegan <pg@bowt.ie>, "David G. Johnston" <david.g.johnston@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2023-10-24T15:56:17Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Prevent duplicate RTEPermissionInfo for plain-inheritance parents

  2. Fix problems when a plain-inheritance parent table is excluded.

  3. Doc: indexUnchanged is strictly a hint.

Hans Buschmann <buschmann@nidsa.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