Re: Why cann't simplify stable function in planning phase?

Hi,

On 2023-02-08 09:57:04 -0500, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> > Note: To be precise this is not about "executions" but about snapshots,
> > and we could probably simplify the function call with isolation levels
> > that maintain a single snapshot (e.g. REPEATABLE READ). But we don't.
> 
> We don't do that because, in fact, execution is *never* done with the same
> snapshot used for planning.  See comment in postgres.c:
> 
>          * While it looks promising to reuse the same snapshot for query
>          * execution (at least for simple protocol), unfortunately it causes
>          * execution to use a snapshot that has been acquired before locking
>          * any of the tables mentioned in the query.  This creates user-
>          * visible anomalies, so refrain.  Refer to
>          * https://postgr.es/m/flat/5075D8DF.6050500@fuzzy.cz for details.
> 
> I'm not entirely sure that that locking argument still holds, but having
> been burned once I'm pretty hesitant to try that again.

Because we now avoid re-computing snapshots, if there weren't any concurrent
commits/aborts, the gain would likely not be all that high anyway.

We should work on gettting rid of the ProcArrayLock acquisition in case we can
reuse the snapshot, though. I think it's doable safely, but when working on
it, I didn't succeed at writing a concise description as to why it's sfae, so
I decided that the rest of the wins are big enough to not focus on it then and
there.

Greetings,

Andres Freund