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

On 03/11/14 22:19, Tom Lane wrote:
> =?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.

Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one. There may be
some internal reasons for it, but for the user executing the
transaction, it's normal to expect the freezing to happen right after
the BEGIN, rather than *after* the first query.

If it is still the intended behavior, I think it should be clearly
documented as such, and a recommendation similar to "issue a 'SELECT 1'
right after BEGIN to freeze the data before any own query" or similar
comment should be added. Again, as I said in my email, the documentation
clearly says that "only sees data committed before the transaction
began". And this is clearly not the real behavior.

> I think there are some examples in the "concurrency control" chapter
> of the manual.

Sure, there are, that was the link I pointed out, but I found no
explicit mention to the fact that I'm raising here.

Regards,

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata