Re: time stops within transaction

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: time stops within transaction
Дата
Msg-id 39EEBDE8.8C1402DE@tpf.co.jp
обсуждение исходный текст
Ответ на Re: time stops within transaction  (Alex Pilosov <alex@pilosoft.com>)
Ответы Re: time stops within transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

Tom Lane wrote:

> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> >>>> Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
> >>>> statement as submitted by a client (libpq)?
> >>
> >> There's never been any reason to make such a distinction.
>
> > There's already a distinction.
> > Snapshot is made per top-level statement and functions/subqueries
> > use the same snapshot as that of top-level statement.
>
> Not so.  SetQuerySnapshot is executed per querytree, not per top-level
> statement --- for example, if a rule generates multiple queries from
> a user statement, SetQuerySnapshot is called again for each query.
>

Is it possible that a rule generates multiple queries from
a read(select)-only statement ? If so,the queries must
be executed under the same snapshot in order to guaran
tee read consistency from user's POV.
As for non-select queries I'm not sure because read
consistency doesn't have much meaning for them.

I just remembered a report from Forest Wilkinson
about a month ago [SQL] SQL functions not locking
properly?

Don't we have to distiguish simple procedure calls
(select func();) and function calls as a part of a query ?
As I mentioned once before,it seems a problem that
arbitrary functions could be called from queries.

As for procedures,it seems preferable that each
statement of them is treated as a top-level query.

Regards.
Hiroshi Inoue



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

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: The lightbulb just went on...
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: AW: Backup, restore & pg_dump