Re: SQLFunctionCache and generic plans - Mailing list pgsql-hackers

From Alexander Pyhalov
Subject Re: SQLFunctionCache and generic plans
Date
Msg-id 337e011069b6831e063bfa346f49bb46@postgrespro.ru
Whole thread Raw
In response to Re: SQLFunctionCache and generic plans  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQLFunctionCache and generic plans
List pgsql-hackers
Tom Lane писал(а) 2025-03-13 21:29:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> Maybe interesting change is the change of error message context
> 
>>  QUERY:   SELECT public.dep_req2() || ' req3b'.
>> -CONTEXT:  SQL function "dep_req3b" during startup
>> +CONTEXT:  SQL function "dep_req3b" statement 1
> 
> I'm not hugely excited about that given that it's just happening in
> one case.  It might be useful to understand exactly why it's changing,
> but I doubt it's something we need to "fix".
> 
>             regards, tom lane

Hi. What happens here that dep_req3b() was already cached and planned.
But when another extension test_ext_req_schema2 is moved to another 
schema,
plan is invalidated. Note that function is already planned, and error
hppens not "during startup", but when we execute the first cached
plan. Now when we are executing the first execution_state, 
init_execution_state()
is called. RevalidateCachedQuery() tries to rewrite query and gets an 
error while
fcache->planning_stmt_number is 1. So, it correctly reports that it's 
the first
statement.
Earlier this error was also called in init_execution_state() (in 
pg_analyze_and_rewrite_withcb()),
but it was considered a startup error (as fcache->func_state) doesn't 
exist
when error is thrown.
-- 
Best regards,
Alexander Pyhalov,
Postgres Professional



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: plperl version on the meson setup summary screen
Next
From: "David G. Johnston"
Date:
Subject: Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.