All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [OSSTEST PATCH 2/2] Executive database: stub out use of LOCK TABLES
Date: Wed, 30 Nov 2016 14:30:09 +0000	[thread overview]
Message-ID: <1480516209-26048-2-git-send-email-ian.jackson@eu.citrix.com> (raw)
In-Reply-To: <1480516209-26048-1-git-send-email-ian.jackson@eu.citrix.com>

We want to improve database performance, and one of the problems is
excessive locking.  Postgresql now has predictate locking, and we
have, we think, eliminated all the places that do not handle a
database transaction failure.  So we can rely on optimistic
concurrency.

So, eliminate all uses of LOCK TABLES.

However, I'm not quite sure that all of the above is actually true -
particularly, with relation to our own error handling.  So, we want to
leave ourselves an escape hatch and an easy reversion path.

The approach adopted is to change the semantics of the transaction
support routines (one in Perl, and one in Tcl) so that the meaning of
all the existing call sites is changed to "do not lock any tables".

But the facility for table locking is retained and any call sites
which still need locking or fixing can use a new parameter format to
say they actually want the locking.

Hopefully this will turn out to be unnecessary.  In that case, in due
course, we can strip out all the locking machinery, abolish all the
corresponding parameters, and so on.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/JobDB/Executive.pm | 8 ++++++++
 tcl/JobDB-Executive.tcl    | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 557cee1..c02ff19 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -45,6 +45,14 @@ sub begin_work ($$$) { #method
 
     $dbh->do("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");
 
+    # $tables used to be [qw(some tables)]
+    #  we ignore that for now
+    # callers can pass for $tables [[qw(some tables)]]
+    #  to override this ignorement, in case it causes trouble
+    return unless @$tables && ref $tables->[0];
+    die '[[qw(some tables)], something] ?' unless @$tables == 1;
+    $tables = $tables->[0];
+
     foreach my $tab (@$tables) {
         $dbh->do("LOCK TABLE $tab IN EXCLUSIVE MODE");
     }
diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index 6225bd9..05677e3 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -258,6 +258,8 @@ proc db-execute-array {arrayvar stmt {body {}}} {
 
 proc lock-tables {tables} {
     # must be inside transaction
+    set first [lshift tables]
+    if {[string compare $first REALLY]} return
     foreach tab $tables {
         db-execute "
 		LOCK TABLE $tab IN EXCLUSIVE MODE
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

      reply	other threads:[~2016-11-30 14:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 14:30 [OSSTEST PATCH 1/2] Executive database: set isolation level in Perl Ian Jackson
2016-11-30 14:30 ` Ian Jackson [this message]

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=1480516209-26048-2-git-send-email-ian.jackson@eu.citrix.com \
    --to=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.