On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote: > Thank you for your comment, Tom. However I think this behavior, as > seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so we can't really mess with it. The spec requires SET TRANSACTION ISOLATION, and you can't implement that if you take a snapshot at BEGIN. > 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. It's more of a difference in when the transaction "begins". Arguably, "BEGIN" says "I intend to begin a new transaction with the next query" rather than "immediately begin executing a new transaction". This concept could be clearer in the docs. > Sure, there are, that was the link I pointed out, but I found no > explicit mention to the fact that I'm raising here. I'm sure it's documented *somewhere*, in that I remember reading about this detail in the docs, but I can't find _where_ in the docs. It doesn't seem to be in: http://www.postgresql.org/docs/current/static/transaction-iso.html where I'd expect. In any case, we simply cannot take the snapshot at BEGIN time, because it's permitted to: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; in a DB that has default serializable isolation or has a SET SESSION CHARACTERISTICS isolation mode of serializable. Note that SET TRANSACTION is SQL-standard. AFAIK deferring the snapshot that's consistent with other RDBMSes that use snapshots, too. The docs of that command allude to, but doesn't explicitly state, the behaviour you mention. http://www.postgresql.org/docs/current/static/sql-set-transaction.html -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
