Nico Sabbi wrote: > /From: > http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html > > " > Read Committed/ [...] > > to me the above sentence sounds inconsistent: it's > asserting that both 1) and 2) apply: > > 1) it never sees ... changes committed during query > execution by concurrent transactions > > 2) Notice that two successive SELECT commands can see > different data, even though they are within a single > transaction, if other transactions commit changes > during execution of the first SELECT > > Can anyone explain, please? 1) means: as long as the first SELECT runs ("during query execution"), you won't see changes made by another transaction. 2) means: when you run a second SELECT, that SELECT will see changes made by other transactions, even if both SELECTs are in one (read commited) transaction. That doesn't sound contradictory to me. There is a difference between "during query execution" and "within a single transaction", maybe that is where your problem comes from. Yours, Laurenz Albe ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
