From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Repeatable read and serializable transactions see data committed after tx start |
Date: | 2014-11-03 21:19:10 |
Message-ID: | 27166.1415049550@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= <aht(at)8Kdata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Vasiliev | 2014-11-03 21:25:34 | Re[3]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |
Previous Message | Fabrízio de Royes Mello | 2014-11-03 21:18:51 | Re: Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |