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
Дата
Msg-id 1328697.1677653602@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set  (Julien Rouhaud <rjuju123@gmail.com>)
Re: BUG #17812: LOCK TABLE IN ACCESS EXCLUSIVE MODE with a view returns an empty tuple set  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Session 4:
> create table tbl2 as select * from view1;
> SELECT 0

> Why is it OK for session 4 to be different here?

Maybe it isn't.  The code flow for CREATE TABLE AS is a bit weird
IIRC, and maybe it's missing a step where we should update the
active snapshot.

> It is unclear to me whether you were instead talking about other sessions
> dropping tables as another way of saying "ACCESS EXCLUSIVE" in which case
> at what lock level should this anomaly go away, and does it?

The originally-proposed tests seemed to all involve either TRUNCATE
or DROP TABLE, which are outside what I consider to be our MVCC
guarantees.  Your example here does seem a bit strange though.
Views generally ought not have different semantics from writing
out the view query in-line.

            regards, tom lane



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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Memory leakage in libpq valgrind test