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