pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Ronan Dunklau <ronan.dunklau@aiven.io>
Subject: Re: SQLFunctionCache and generic plans
Date: Fri, 14 Mar 2025 09:33:48 +0300
Message-ID: <337e011069b6831e063bfa346f49bb46@postgrespro.ru> (raw)
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>

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





view thread (49+ messages)  latest in thread

Message-ID: <337e011069b6831e063bfa346f49bb46@postgrespro.ru>
Permalink:  ../337e011069b6831e063bfa346f49bb46@postgrespro.ru/
Also on:    postgresql.org/message-id/337e011069b6831e063bfa346f49bb46@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: a.pyhalov@postgrespro.ru, tgl@sss.pgh.pa.us, pavel.stehule@gmail.com, aekorotkov@gmail.com, ronan.dunklau@aiven.io
  Subject: Re: SQLFunctionCache and generic plans
  In-Reply-To: <337e011069b6831e063bfa346f49bb46@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox