From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: A few beginner's questions concerning concurrency control |
Date: | 2004-06-29 09:51:41 |
Message-ID: | 20040629115141.G559@hermes.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Question #3
> =========
> In some places it is said that a transaction that only reads does not lock
> any table or row, and is never blocked. But if a transaction T1 modifies a
> row r, and at the same time transaction T2 selects r, then T2 need to wait
> until T1 finishes (as T1 might have deleted the row, or modified it in a way
> that would cause T1 not to need it, as the row does not satisfy T2?s WHERE
> clause).
The answer lies in the application of MVCC. You already said above
that each transaction sees tuples as if it ran all by itself
(which is only true for some of the transaction isolation levels).
Aborts (if attempts to write to changed data occur) are involved.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
From | Date | Subject | |
---|---|---|---|
Next Message | Yoram Biberman | 2004-06-29 09:55:50 | A few beginner's questions concerning concurrency control |
Previous Message | Najib Abi Fadel | 2004-06-29 07:47:45 | dividing time ?? |