It's now clearer for me. Thanks a lot for you long explanation.
--
Stéphane
Richard Huxton wrote:
On Wednesday 10 September 2003 12:54, Stéphane Cazeaux wrote:
Richard Huxton wrote:
Client2's first SELECT started before you commited the INSERT, the second
SELECT
Richard Huxton wrote:
On Wednesday 10 September 2003 08:34, Stéphane Cazeaux wrote:
Client 1:
BEGIN;
SELECT count FROM test_count FOR UPDATE; --> returns the only entry "1"
Client 2 :
BEGIN;
SELECT count FROM test_count FOR UPDATE; --> this query is blocked, ok
On Wednesday 10 September 2003 12:54, Stéphane Cazeaux wrote:
> Richard Huxton wrote:
> >
> >Client2's first SELECT started before you commited the INSERT, the second
> >SELECT started after you commited. Since you are using READ COMMITTED you
> > can read the results of transactions committed *bef
=?ISO-8859-1?Q?St=E9phane_Cazeaux?= <[EMAIL PROTECTED]> writes:
> I'm ok about this, but, if I try exactly the same scenario, where I
> replace the INSERT by a DELETE, the first SELECT of the client 2 won't
> return any row. This is the same behaviour with an UPDATE. If client 1
> updates the ro
