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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set
Дата
Msg-id CAKFQuwb5U84yZGRRiGsRtLm3D3_jtc=TtXE=7y-z0ORg+Jy1bQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set  (Keyerror Smart <smartkeyerror@gmail.com>)
Ответы Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Tue, Feb 28, 2023 at 8:02 PM Keyerror Smart <smartkeyerror@gmail.com> wrote:
OK, I get it. Thanks for your explanation.

You may find the following to be informative as well.


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.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Keyerror Smart
Дата:
Сообщение: Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set