Re: [HACKERS] What happens If a table changes during a query/procedure execution

2011-03-09 Thread Pavel Stehule
2011/3/9 Vlad Arkhipov : > 09.03.2011 18:54, Nicolas Barbier: >> >> 2011/3/9 Vlad Arkhipov: >> >> >>> >>> Let there are two transactions that were created with read commited >>> isolation level. In the first one we're executing a SELECT query: >>> SELECT * FROM t UNION ALL SELECT * FROM t; >>> >>>

Re: [HACKERS] What happens If a table changes during a query/procedure execution

2011-03-09 Thread Vlad Arkhipov
09.03.2011 18:54, Nicolas Barbier: 2011/3/9 Vlad Arkhipov: Let there are two transactions that were created with read commited isolation level. In the first one we're executing a SELECT query: SELECT * FROM t UNION ALL SELECT * FROM t; In the second transaction we're modifying the same tab

Re: [HACKERS] What happens If a table changes during a query/procedure execution

2011-03-09 Thread Nicolas Barbier
2011/3/9 Nicolas Barbier : > Note that the standard defines things that must never happen in the > case of READ COMMITTED, it does not specify that one *must* be able to > see the stuff as committed by previous transactions, for example. Hmm, make that "stuff as committed by concurrent transactio

Re: [HACKERS] What happens If a table changes during a query/procedure execution

2011-03-09 Thread Nicolas Barbier
2011/3/9 Vlad Arkhipov : > Let there are two transactions that were created with read commited > isolation level. In the first one we're executing a SELECT query: > SELECT * FROM t UNION ALL SELECT * FROM t; > > In the second transaction we're modifying the same table: > INSERT INTO t DEFAULT VALU