When revalidate_rectypeid() acts to update a stale record type OID
in plpgsql's data structures, it fixes the active PLpgSQL_rec struct
as well as the PLpgSQL_type struct it references. However, the latter
is shared across function executions while the former is not. In a
later function execution, the PLpgSQL_rec struct would be reinitialized
by copy_plpgsql_datums and would then contain a stale type OID,
typically leading to "could not open relation with OID NNNN" errors.
revalidate_rectypeid() can easily fix this, fortunately, just by
treating typ->typoid as authoritative.
Per report and diagnosis from Ashutosh Sharma, though this is not his
suggested fix. Back-patch to v11 where this code came in.
Discussion: https://postgr.es/m/CAE9k0Pkd4dZwt9J5pS9xhJFWpUtqs05C9xk_GEwPzYdV=GxwWg@mail.gmail.com
44
(1 row)
+select sillyaddtwo(43);
+ sillyaddtwo
+-------------
+ 45
+(1 row)
+
-- check access to system columns in a record variable
create function sillytrig() returns trigger language plpgsql as
$$begin
Assert(typ != NULL);
if (typ->tcache &&
typ->tcache->tupDesc_identifier == typ->tupdesc_id)
- return; /* known up-to-date */
+ {
+ /*
+ * Although *typ is known up-to-date, it's possible that rectypeid
+ * isn't, because *rec is cloned during each function startup from a
+ * copy that we don't have a good way to update. Hence, forcibly fix
+ * rectypeid before returning.
+ */
+ rec->rectypeid = typ->typoid;
+ return;
+ }
/*
* typcache entry has suffered invalidation, so re-look-up the type name
select sillyaddtwo(42); -- fail
create table mutable2(f0 text, f1 int, f2 text);
select sillyaddtwo(42);
+select sillyaddtwo(43);
-- check access to system columns in a record variable