From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | cstork+postgresql(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: BUG #18131: PL/pgSQL: regclass procedure parameter wrongly memoized(?) |
Date: | 2023-09-23 16:39:04 |
Message-ID: | 1332569.1695487144@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The following condensed recipe reproduces the error:
> create procedure callee(t regclass)
> language plpgsql as
> $body$
> begin
> raise notice 'callee: oid = %', t::oid;
> execute 'table ' || t;
> end;
> $body$;
> create procedure caller()
> language plpgsql as
> $body$
> begin
> create table table_name ();
> raise notice 'caller: oid = %', 'table_name'::regclass::oid;
> call callee('table_name');
> drop table table_name;
> end;
> $body$;
> call caller(); -- OK
> call caller(); -- ERROR: callee executed with OID of previous invocation!
Hmm. It's not just regclass: we're failing to track *any* dependencies
of the compiled CallStmt. So you can also break it by, say, dropping
and recreating the "callee" procedure.
The attached quick hack fixes the reported symptoms, but I wonder
if there is a better place to do it.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v1-track-dependencies-of-CallStmt.patch | text/x-diff | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-09-23 20:43:28 | BUG #18132: llvm-jit does not build with LLVM 17 |
Previous Message | Michael Paquier | 2023-09-23 04:44:18 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |