Re: SQLFunctionCache and generic plans
От | Alexander Pyhalov |
---|---|
Тема | Re: SQLFunctionCache and generic plans |
Дата | |
Msg-id | 337e011069b6831e063bfa346f49bb46@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: SQLFunctionCache and generic plans (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SQLFunctionCache and generic plans
|
Список | 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 по дате отправления: