MIME-Version: 1.0
Date: Fri, 14 Mar 2025 09:33:48 +0300
From: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Alexander Korotkov
 <aekorotkov@gmail.com>, pgsql-hackers@lists.postgresql.org, Ronan Dunklau
 <ronan.dunklau@aiven.io>
Subject: Re: SQLFunctionCache and generic plans
In-Reply-To: <2827970.1741890560@sss.pgh.pa.us>
References: <8216639.NyiUUSuA9g@aivenlaptop>
 <3084885.1675783797@sss.pgh.pa.us>
 <b69515864a7021505340f85476dc111e@postgrespro.ru>
 <CAPpHfdue9RVJKo33jKwrCeEXec0BTTH7CTxVcyXGMbfMExaGLA@mail.gmail.com>
 <758251661a3e8760ff52dd5c672a7505@postgrespro.ru>
 <CAFj8pRCoR9B+Ap70TQqWUa0PeeEk94D6VW20YbWN2Pm4b6-JMQ@mail.gmail.com>
 <30f02ca545915627905fbe3f23d93ec1@postgrespro.ru>
 <2275997.1737138456@sss.pgh.pa.us>
 <ad7296dd981c5f8eb76ff129913a55fd@postgrespro.ru>
 <51ebc5f3b846ce279b75ac4f5e5ac33f@postgrespro.ru>
 <CAFj8pRD2Fa84HoH_R_S5aKngyA6a+Au7U6NyidfBMrwEjFAc9g@mail.gmail.com>
 <401652.1738598448@sss.pgh.pa.us>
 <CAFj8pRC_4gEfmDoB5KbacNDdt3e6Tnf1z1BFK=MVp3+2kcDVqw@mail.gmail.com>
 <CAFj8pRA7MFTfUPwDDWtghaUvAjbrMHFUPbHyLSX3h8+FDw4WFg@mail.gmail.com>
 <445556.1738612687@sss.pgh.pa.us> <464677.1738620525@sss.pgh.pa.us>
 <1fc18af56d5fb27bf3e153ffaa2ed70d@postgrespro.ru>
 <2615770.1740688857@sss.pgh.pa.us>
 <448c63cf9b4f917c01802309b9c29eb9@postgrespro.ru>
 <CAFj8pRDWDeF2cC+pCjLHJno7KnK5kdtjYN-f933R! HS7UneArFw@mail.gmail.com>
 <CAFj8pRD0diy5VDP=8B9au5sk_yRknCWqZx35VniBtP_OA4aJNw@mail.gmail.com>
 <2827970.1741890560@sss.pgh.pa.us>
Message-ID: <337e011069b6831e063bfa346f49bb46@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/337e011069b6831e063bfa346f49bb46%40postgrespro.ru>
Precedence: bulk

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