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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: tender wang <tndrwang(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why cann't simplify stable function in planning phase?
Date: 2023-02-08 14:57:04
Message-ID: 3485170.1675868224@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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(dot)6050500(at)fuzzy(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2023-02-08 15:12:39 Re: OpenSSL 3.0.0 vs old branches
Previous Message Dag Lem 2023-02-08 14:31:20 Re: daitch_mokotoff module