From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 2/2] Executive DB: Reduce strength of DB locks
Date: Fri, 11 Dec 2015 16:37:39 +0000 [thread overview]
Message-ID: <1449851859.30975.66.camel@citrix.com> (raw)
In-Reply-To: <1449850984-21651-2-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2015-12-11 at 16:23 +0000, Ian Jackson wrote:
> The purpose of these locks is partly to prevent transactions being
> aborted (which I'm not sure the existing code would in practice cope
> with, although this is a bug) and also to avoid bugs due to the fact
> that
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> not mean that the transactions are necessarily serialisable!
^does not?
> http://www.postgresql.org/docs/8.3/static/transaction-iso.html
>
> In SQL in general it is possible for read-only transactions to
> conflict with writing transactions.
>
> However, in PostgreSQL this is not a problem 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
>
> So a read transaction cannot cause a write transaction to abort, nor
> vice versa. So there is no need to have the database explicit table
> locks prevent concurrent read access.
>
> Preventing concurrent read access means that simple and urgent updates
> can be unnecessarily delayed by long-running reader transactions in
> the history reporters and archaelogists.
archaeologists
> So, reduce the lock mode from ACCESS EXCLUSIVE to ACCESS. This still
> conflicts with all kinds of updates and prospective updates, but no
> longer with SELECT:
> http://www.postgresql.org/docs/8.3/static/explicit-locking.html
>
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> Osstest/JobDB/Executive.pm | 2 +-
> tcl/JobDB-Executive.tcl | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
> index 69cb276..124e7c0 100644
> --- a/Osstest/JobDB/Executive.pm
> +++ b/Osstest/JobDB/Executive.pm
> @@ -43,7 +43,7 @@ sub begin_work ($$$) { #method
>
> return if $ENV{'OSSTEST_DEBUG_NOSQLLOCK'};
> foreach my $tab (@$tables) {
> - $dbh->do("LOCK TABLE $tab IN ACCESS EXCLUSIVE MODE");
> + $dbh->do("LOCK TABLE $tab IN EXCLUSIVE MODE");
> }
> }
>
> diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
> index f37bbaf..a3dbb9e 100644
> --- a/tcl/JobDB-Executive.tcl
> +++ b/tcl/JobDB-Executive.tcl
> @@ -133,7 +133,7 @@ proc lock-tables {tables} {
> # must be inside transaction
> foreach tab $tables {
> db-execute "
> - LOCK TABLE $tab IN ACCESS EXCLUSIVE MODE
> + LOCK TABLE $tab IN EXCLUSIVE MODE
> "
> }
> }
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-12-11 16:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 16:23 [OSSTEST PATCH 1/2] Executive DB: Eliminate SQL locking for read-only transactions Ian Jackson
2015-12-11 16:23 ` [OSSTEST PATCH 2/2] Executive DB: Reduce strength of DB locks Ian Jackson
2015-12-11 16:37 ` Ian Campbell [this message]
2015-12-11 16:53 ` Ian Jackson
2015-12-11 16:35 ` [OSSTEST PATCH 1/2] Executive DB: Eliminate SQL locking for read-only transactions Ian Campbell
2015-12-11 16:52 ` Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1449851859.30975.66.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.