Re: Repeatable read and serializable transactions see data committed after tx start

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Repeatable read and serializable transactions see data committed after tx start
Дата
Msg-id 27166.1415049550@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Repeatable read and serializable transactions see data committed after tx start  (Álvaro Hernández Tortosa <aht@8Kdata.com>)
Ответы Re: Repeatable read and serializable transactions see data committed after tx start  (Álvaro Hernández Tortosa <aht@8Kdata.com>)
Список pgsql-hackers
Álvaro Hernández Tortosa <aht@8Kdata.com> writes:
>      IMHO, from a user perspective the transaction begins when the BEGIN 
> command is issued. If I really want to see a "frozen" view of the 
> database before any real SELECT, I have to issue another query like 
> "SELECT 1". This seems odd to me. I understand tx snapshot may be 
> deferred until real execution for performance reasons, but it is 
> confusing from a user perspective. Is this really expected, or is it a 
> bug? Am I having a bad day and missing some point here? ^_^

It's expected.  Without this behavior, you could not take out any locks
before freezing the transaction snapshot, which would be a bad thing.
I think there are some examples in the "concurrency control" chapter
of the manual.
        regards, tom lane



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

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Следующее
От: Alexey Vasiliev
Дата:
Сообщение: Re[3]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code