On 03/11/14 22:19, Tom Lane wrote:
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= <a...@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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
