Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set

On Tue, Feb 28, 2023 at 8:02 PM Keyerror Smart <smartkeyerror(at)gmail(dot)com>
wrote:

> OK, I get it. Thanks for your explanation.
>

You may find the following to be informative as well.

https://github.com/postgres/postgres/commit/532994299e2ff208a58376134fab75f5ae471e41
https://www.postgresql.org/message-id/flat/5075D8DF.6050500%40fuzzy.cz

In short this seems to fall into "maybe we can do better in the future" -
though it seems that future has not yet come to fruition.

To my knowledge this dynamic isn't called out anywhere though it seems
almost obvious once pointed out.

There still seems to be something off here:

> unfortunately it causes execution to use a snapshot that has been
acquired before locking any of the tables mentioned in the query

I went down the path that the planner should be the one realizing that the
view-using query has a lock it cannot grab - on the rewritten query's
introduction of the new table - and it should have blocked in the planner,
resulting in the acquisition of the execution-time snapshot in that case as
well.

Apparently the planner gets to bypass a check (that blocks) that parse
analysis has to perform. Thus locking of tables does happen for the ones
named in the query text itself?

David J.