On Fri, 2015-12-11 at 16:23 +0000, Ian Jackson wrote: > Our transactions generally run with > SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; > (which, incidentally, does not mean that the transactions are > necessarily serialisable!) > > In SQL in general it is possible for a read-only transaction to fail > and need to be retried because some writer has updated things. > > However, in PostgreSQL this is not possible because Postgres uses > multi-version concurrency control: it retains the old version of the > data while the read transaction is open: > http://www.postgresql.org/docs/8.3/static/transaction-iso.html > > (And, of course, SQLite uses MVCC too, and all transactions in SQLite > are fully serialisable.) > > So it is not necessary for these read-only operations to take out > locks. When they do so they can unnecessarily block other important > work for long periods of time. > > With this change, we go further from the ability to support databases > other than PostgreSQL and SQLite. However, such support was very > distant anyway because of differences in SQL syntax and semantics, our > reliance in Executive mode on sql's command line utilities, and so on. > > We retain the db_retry framing because (a) although the retry loop is > not necessary in these cases, the transaction framing is (b) it will > make it slightly easier to reverse this decision in the future if we > ever decide to do so (c) it is less code churn. > > Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com>
Acked-by: Ian Campbell <ian.campb...@citrix.com> (I haven't actually checked that everywhere you have changed is actually r/o, nor whether you have found every r/o operation). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
