Hi!<br /><br /> Given a transaction started with "BEGIN.... (REPEATABLE READ | SERIALIZABLE)", if a concurrent
sessioncommits some data before *any* query within the first transaction, that committed data is seen by the
transaction.This is not what I'd expect. Specifically, the documentation states that:<br /><br /> "The Repeatable Read
isolationlevel only sees data committed before the transaction began;" [1]<br /><br /> IMHO, from a user
perspectivethe transaction begins when the BEGIN command is issued. If I really want to see a "frozen" view of the
databasebefore any real SELECT, I have to issue another query like "SELECT 1". This seems odd to me. I understand tx
snapshotmay be deferred until real execution for performance reasons, but it is confusing from a user perspective. Is
thisreally expected, or is it a bug? Am I having a bad day and missing some point here? ^_^<br /><br /> Regards,<br
/><br/> Álvaro<br /><br /><br /> [1] <a class="moz-txt-link-freetext"
href="http://www.postgresql.org/docs/devel/static/transaction-iso.html">http://www.postgresql.org/docs/devel/static/transaction-iso.html</a><br
/><br/><br /> P.S. In case it wasn't clear what I meant, here's an example:<br /><br /><br /> Session 1
Session 2<br /><br /> CREATE TABLE i (i
integer);<br/> BEGIN ISOLATION LEVEL REPEATABLE READ;<br />
INSERT INTO i VALUES (1);<br /> SELECT i FROM i; -- returns 1
row,value 1<br /> -- should return empty set<br />
INSERT INTO i VALUES (2);<br /> SELECT i FROM i; -- returns 1 row, value
1<br/> -- returns, as it should, the same as the previous query<br /><br /><br /> In the first select, I'd have
expectedto have no rows. If a "SELECT 1" is issued after BEGIN, there are no rows found.<br /><br /><pre
class="moz-signature"cols="72">--
Álvaro Hernández Tortosa
-----------
8Kdata
</pre>