public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Alexander Pyhalov <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: [email protected]
Cc: Ronan Dunklau <[email protected]>
Subject: Re: SQLFunctionCache and generic plans
Date: Mon, 31 Mar 2025 10:50:43 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <8216639.NyiUUSuA9g@aivenlaptop>
	<[email protected]>
	<[email protected]>
	<CAPpHfdue9RVJKo33jKwrCeEXec0BTTH7CTxVcyXGMbfMExaGLA@mail.gmail.com>
	<[email protected]>
	<CAFj8pRCoR9B+Ap70TQqWUa0PeeEk94D6VW20YbWN2Pm4b6-JMQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFj8pRD2Fa84HoH_R_S5aKngyA6a+Au7U6NyidfBMrwEjFAc9g@mail.gmail.com>
	<[email protected]>
	<CAFj8pRC_4gEfmDoB5KbacNDdt3e6Tnf1z1BFK=MVp3+2kcDVqw@mail.gmail.com>
	<CAFj8pRA7MFTfUPwDDWtghaUvAjbrMHFUPbHyLSX3h8+FDw4WFg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFj8pRDWDeF2cC+pCjLHJno7KnK5kdtjYN-f933R! ! ! ! ! [email protected]>
	<CAFj8pRD0diy5VDP=8B9au5sk_yRknCWqZx35VniBtP_OA4aJNw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Alexander Pyhalov <[email protected]> writes:
> I've looked through it and made some tests, including ones which
> caused me to create separate context for planing. Was a bit worried
> that it has gone, but now, as fcache->fcontext is deleted in the end
> of function execution, I don't see leaks, which were the initial
> reason for introducing it.

Yeah.  As it's set up in v10, we do parsing work in the caller's
context (which is expected to be short-lived) when creating or
recreating the long-lived cache entry.  However, planning work
(if needed) is done in the fcontext, since that will happen within
init_execution_state which is called after fmgr_sql has switched into
the fcontext.  I thought about switching back to the caller's context
but decided that it wouldn't really be worth the trouble.  For a
non-SRF there's no meaningful difference anyway.  For a SRF, it'd mean
that planning cruft survives till end of execution of the SRF rather
than possibly going away when the first row is returned.  But we
aren't looping: any given query within the SRF is planned only once
during an execution of the function.  So there's no possibility of
indefinite accumulation of leakage.

If we wanted to improve that, my inclination would be to try to
not switch into the fcontext for the whole of fmgr_sql, but only
use it explicitly for allocations that need to survive.  But I
don't think that'll save much, so I think any such change would
be best left for later.  The patch is big enough already.

			regards, tom lane

view thread (35+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: SQLFunctionCache and generic plans
  In-Reply-To: <[email protected]>

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

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