All of lore.kernel.org
 help / color / mirror / Atom feed
* [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
@ 2015-12-15 16:26 Ian Jackson
  2015-12-15 16:26 ` [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count Ian Jackson
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 16:26 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Jackson, Ian Campbell

Previously we would retry all COMMITs but nothing else.  This is
correct for SQLite3 but not for PostgreSQL.

We got away with it before because of the heavyweight locking of even
long-running read-only transactions, but now the LOCK TABLEs can fail
(at least in a mixed-version system, and perhaps even in a system with
only new code).

So: cover all of the database work in db_retry with the eval, and
explicitly ask the JobDB adaptation layer (via a new need_retry
method) whether to go around again.  We tell the JobDB layer whether
the problem was during commit, so that we can avoid making any overall
semantic change to the interaction with SQLite3.

In the PostgreSQL case, the db handle can be asked whether there was
an error and what the error code was.  Deadlock has its own error
code.

I have tested this with the following rune:

 OSSTEST_CONFIG=/u/iwj/.xen-osstest/config:local-config.test-database_iwj perl -w -MData::Dumper -e 'use strict; use Osstest::Executive; use Osstest; csreadconfig(); print Dumper($dbh_tests->{AutoCommit}); eval { $dbh_tests->do("BOGUS"); }; db_begin_work($dbh_tests, [qw(flights resources)])'

adding a sleep(2) to the loop Osstest::JobDB::Executive::begin_work,
and running a second copy of the rune with the tables to lock in the
other order.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest.pm                  |   34 +++++++++++++++++++++-------------
 Osstest/JobDB/Executive.pm  |    7 +++++++
 Osstest/JobDB/Standalone.pm |    5 +++++
 3 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index d4ddda7..a39ae42 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -288,20 +288,28 @@ sub db_retry ($$$;$$) {
     for (;;) {
         $pre->();
 
-        db_begin_work($dbh, $tables);
-        if (defined $fl) {
-            die unless $dbh eq $dbh_tests;
-            $mjobdb->dbfl_check($fl,$flok);
-        }
-        $db_retry_stop= 0;
-        $r= &$body;
-        if ($db_retry_stop) {
-            $dbh->rollback();
-            last if $db_retry_stop eq 'abort';
-        } else {
-            last if eval { $dbh->commit(); 1; };
-        }
+	my $committing = 0;
+	eval {
+	    db_begin_work($dbh, $tables);
+	    if (defined $fl) {
+		die unless $dbh eq $dbh_tests;
+		$mjobdb->dbfl_check($fl,$flok);
+	    }
+	    $db_retry_stop= 0;
+	    $r= &$body;
+	    if ($db_retry_stop) {
+		$dbh->rollback();
+		last if $db_retry_stop eq 'abort';
+		next;
+	    }
+	    $committing = 1;
+	    $dbh->commit();
+	};
+	last if !length $@;
+	die $@ unless $mjobdb->need_retry($dbh, $committing);
         die "$dbh $body $@ ?" unless $retries-- > 0;
+	eval { $dbh->rollback(); };
+	print STDERR "DB conflict (messages above may refer); retrying...\n";
         sleep(1);
     }
     return $r;
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 124e7c0..6fb77a4 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -47,6 +47,13 @@ sub begin_work ($$$) { #method
     }
 }
 
+sub need_retry ($$$) {
+    my ($jd, $dbh,$committing) = @_;
+    return
+	$dbh_tests->err()==7 &&
+	($dbh_tests->state =~ m/^40P01/); # DEADLOCK DETECTED
+}
+
 sub current_flight ($) { #method
     return $ENV{'OSSTEST_FLIGHT'};
 }
diff --git a/Osstest/JobDB/Standalone.pm b/Osstest/JobDB/Standalone.pm
index 431ba5a..98d0173 100644
--- a/Osstest/JobDB/Standalone.pm
+++ b/Osstest/JobDB/Standalone.pm
@@ -41,6 +41,11 @@ augmentconfigdefaults(
 sub new { return bless {}, $_[0]; };
 
 sub begin_work { }
+sub need_retry ($$$) {
+    my ($jd, $dbh,$committing) = @_;
+    return $committing;
+}
+
 sub dbfl_check { }
 
 sub open ($) {
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count
  2015-12-15 16:26 [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Jackson
@ 2015-12-15 16:26 ` Ian Jackson
  2015-12-15 16:33   ` Ian Campbell
  2015-12-15 16:26 ` [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch Ian Jackson
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 16:26 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Jackson, Ian Campbell

It seems to me that this deadlock might actually become fairly common
in some setups.  There is little harm in trying it for 100s rather
than 20s, and there maybe some benefit.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest.pm |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest.pm b/Osstest.pm
index a39ae42..c77d960 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -282,7 +282,7 @@ sub db_retry ($$$;$$) {
     my ($pre,$body) =
         (ref $code eq 'ARRAY') ? @$code : (sub { }, $code);
 
-    my $retries= 20;
+    my $retries= 100;
     my $r;
     local $db_retry_stop;
     for (;;) {
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch
  2015-12-15 16:26 [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Jackson
  2015-12-15 16:26 ` [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count Ian Jackson
@ 2015-12-15 16:26 ` Ian Jackson
  2015-12-15 16:34   ` Ian Campbell
  2015-12-15 16:26 ` [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries Ian Jackson
  2015-12-15 16:33 ` [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Campbell
  3 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 16:26 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Jackson, Ian Campbell

Previously we would retry only the body, but not LOCK TABLEs.

We got away with it before because of the heavyweight locking of even
long-running read-only transactions, but now the LOCK TABLEs can fail
(at least in a mixed-version system, and perhaps even in a system with
only new code).

Additionally, if one of the LOCK TABLEs fails, the code's use of the
db handle becomes stuck because of the failed transaction: the error
is caught by the daemon's main loop error handler, but the db handle
is not subjected to ROLLBACK and all future attempts to use it will
fail.

So: move the LOCK TABLEs (and the SET TRANSACTION) into the catch, so
that deadlocks in LOCK TABLEs are retried (after ROLLBACK).

The COMMIT remains outside the eval but this should be unaffected by
DB deadlocks if the LOCK TABLEs are right.

Note that this code does not attempt to distinguish DB deadlock errors
from other errors.  Arguably this is quite wrong.  Fixing it to
distinguish deadlocks is awkward because pg_execute does not leave the
error information anywhere it can be found.  Contrary to what the
documentation seems to imply, it does not set errorCode (!)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tcl/JobDB-Executive.tcl |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index a3dbb9e..8e45ea7 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -228,9 +228,11 @@ proc transaction {tables script} {
     while 1 {
         set ol {}
         db-execute BEGIN
-        db-execute "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"
-        lock-tables $tables
-	set rc [catch { uplevel 1 $script } result]
+	set rc [catch {
+	    db-execute "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"
+	    lock-tables $tables
+	    uplevel 1 $script
+	} result]
 	if {!$rc} {
 	    if {[catch {
 		db-execute COMMIT
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries
  2015-12-15 16:26 [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Jackson
  2015-12-15 16:26 ` [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count Ian Jackson
  2015-12-15 16:26 ` [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch Ian Jackson
@ 2015-12-15 16:26 ` Ian Jackson
  2015-12-15 16:35   ` Ian Campbell
  2015-12-15 16:33 ` [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Campbell
  3 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 16:26 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Jackson, Ian Campbell

If there is something fundamentally wrong, don't just sit looping
around every 500ms.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 tcl/JobDB-Executive.tcl |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index 8e45ea7..7dba497 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -224,6 +224,8 @@ proc step-set-status {flight job stepno st} {
 }
 
 proc transaction {tables script} {
+    global errorInfo errorCode
+    set retries 100
     db-open
     while 1 {
         set ol {}
@@ -239,6 +241,10 @@ proc transaction {tables script} {
 	    } emsg]} {
 		puts "commit failed: $emsg; retrying ..."
 		db-execute ROLLBACK
+		if {[incr retries -1] <= 0} {
+		    error \
+ "commit failed, too many retries: $emsg\n$errorInfo\n$errorCode\n"
+		}
 		after 500
 		continue
 	    }
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 16:26 [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Jackson
                   ` (2 preceding siblings ...)
  2015-12-15 16:26 ` [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries Ian Jackson
@ 2015-12-15 16:33 ` Ian Campbell
  2015-12-15 16:41   ` Ian Jackson
  3 siblings, 1 reply; 13+ messages in thread
From: Ian Campbell @ 2015-12-15 16:33 UTC (permalink / raw)
  To: Ian Jackson, xen-devel

On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> 
> +sub need_retry ($$$) {
> +    my ($jd, $dbh,$committing) = @_;
> +    return
> +	$dbh_tests->err()==7 &&
> +	($dbh_tests->state =~ m/^40P01/); # DEADLOCK DETECTED

How come this return value doesn't need to include $committing in some way?

Also, "DEADLOCK DETECTED" presumably only occurs when fighting with some
other client, as opposed to this client being broken and doing "LOCK A;
....; LOCK A"? Or if not we have a retry limit so such code won't just spin
forever.

Ian.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count
  2015-12-15 16:26 ` [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count Ian Jackson
@ 2015-12-15 16:33   ` Ian Campbell
  0 siblings, 0 replies; 13+ messages in thread
From: Ian Campbell @ 2015-12-15 16:33 UTC (permalink / raw)
  To: Ian Jackson, xen-devel

On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> It seems to me that this deadlock might actually become fairly common
> in some setups.  There is little harm in trying it for 100s rather
> than 20s, and there maybe some benefit.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch
  2015-12-15 16:26 ` [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch Ian Jackson
@ 2015-12-15 16:34   ` Ian Campbell
  0 siblings, 0 replies; 13+ messages in thread
From: Ian Campbell @ 2015-12-15 16:34 UTC (permalink / raw)
  To: Ian Jackson, xen-devel

On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> Previously we would retry only the body, but not LOCK TABLEs.
> 
> We got away with it before because of the heavyweight locking of even
> long-running read-only transactions, but now the LOCK TABLEs can fail
> (at least in a mixed-version system, and perhaps even in a system with
> only new code).
> 
> Additionally, if one of the LOCK TABLEs fails, the code's use of the
> db handle becomes stuck because of the failed transaction: the error
> is caught by the daemon's main loop error handler, but the db handle
> is not subjected to ROLLBACK and all future attempts to use it will
> fail.
> 
> So: move the LOCK TABLEs (and the SET TRANSACTION) into the catch, so
> that deadlocks in LOCK TABLEs are retried (after ROLLBACK).
> 
> The COMMIT remains outside the eval but this should be unaffected by
> DB deadlocks if the LOCK TABLEs are right.
> 
> Note that this code does not attempt to distinguish DB deadlock errors
> from other errors.  Arguably this is quite wrong.  Fixing it to
> distinguish deadlocks is awkward because pg_execute does not leave the
> error information anywhere it can be found.  Contrary to what the
> documentation seems to imply, it does not set errorCode (!)
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries
  2015-12-15 16:26 ` [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries Ian Jackson
@ 2015-12-15 16:35   ` Ian Campbell
  0 siblings, 0 replies; 13+ messages in thread
From: Ian Campbell @ 2015-12-15 16:35 UTC (permalink / raw)
  To: Ian Jackson, xen-devel

On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> If there is something fundamentally wrong, don't just sit looping
> around every 500ms.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 16:33 ` [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Campbell
@ 2015-12-15 16:41   ` Ian Jackson
  2015-12-15 16:47     ` Ian Campbell
  2015-12-15 17:01     ` Ian Jackson
  0 siblings, 2 replies; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 16:41 UTC (permalink / raw)
  To: Ian Campbell; +Cc: xen-devel

Ian Campbell writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL"):
> On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> > +sub need_retry ($$$) {
> > +    my ($jd, $dbh,$committing) = @_;
> > +    return
> > +	$dbh_tests->err()==7 &&
> > +	($dbh_tests->state =~ m/^40P01/); # DEADLOCK DETECTED
> 
> How come this return value doesn't need to include $committing in some way?

$committing is just there as a fudge for the benefit of SQLite3, which
only fails during COMMIT.  In PostgreSQL we can always tell by the
error code.

> Also, "DEADLOCK DETECTED" presumably only occurs when fighting with some
> other client, as opposed to this client being broken and doing "LOCK A;
> ....; LOCK A"? Or if not we have a retry limit so such code won't just spin
> forever.

Databases (at least PostgreSQL) take care of all that kind of thing:
they will detect the deadlock.  IDK what happens if you try to lock
the same table twice in the same transaction but it will either work
or fail with a deadlock error.  If it fails with a deadlock error
then as you say the retry limit will catch it.

(Deadlocks involving perhaps multiple processes, doing IPC outside the
DB, and with multiple db connections, are not necessarily detectable
by the DB.  But this change does not make that possibility any worse.)

Ian.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 16:41   ` Ian Jackson
@ 2015-12-15 16:47     ` Ian Campbell
  2015-12-15 17:01     ` Ian Jackson
  1 sibling, 0 replies; 13+ messages in thread
From: Ian Campbell @ 2015-12-15 16:47 UTC (permalink / raw)
  To: Ian Jackson; +Cc: xen-devel

On Tue, 2015-12-15 at 16:41 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl:
> Retry all deadlocks in PostgreSQL"):
> > On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> > > +sub need_retry ($$$) {
> > > +    my ($jd, $dbh,$committing) = @_;
> > > +    return
> > > +	$dbh_tests->err()==7 &&
> > > +	($dbh_tests->state =~ m/^40P01/); # DEADLOCK DETECTED
> > 
> > How come this return value doesn't need to include $committing in some
> > way?
> 
> $committing is just there as a fudge for the benefit of SQLite3, which
> only fails during COMMIT.  In PostgreSQL we can always tell by the
> error code.

But the above doesn't check for the commit failed/conflict code either.

Ian.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 16:41   ` Ian Jackson
  2015-12-15 16:47     ` Ian Campbell
@ 2015-12-15 17:01     ` Ian Jackson
  2015-12-15 17:20       ` Ian Jackson
  1 sibling, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 17:01 UTC (permalink / raw)
  To: Ian Campbell, xen-devel; +Cc: robert.hu

Ian Jackson writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL"):
> [stuff]

Thanks, we discussed this in person, and I have added your ack and
force pushed it to osstest production.

The Massachusetts instance is currently broken because the ownerdaemon
is broken.  So I am going to update the owner and queue daemons, and
restart everything, and then remove the Mass stop file.

The Cambridge instance doesn't have the SQL locking changes yet, but
it would start testing the new osstest which might start to cause
trouble.  So I have dropped a stop file there now.  When Cambridge has
drained, probably tomorrow, I will update the daemons there (but not
push anything to the main in-use trees).

Any other instances (eg, Intel?) running in Executive mode need to get
the updates to the owner and queue daemons before starting to use the
new osstest.git for actual test flights.

Ian.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 17:01     ` Ian Jackson
@ 2015-12-15 17:20       ` Ian Jackson
  2015-12-16  1:39         ` Robert Hu
  0 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2015-12-15 17:20 UTC (permalink / raw)
  To: Ian Campbell, xen-devel, robert.hu

Ian Jackson writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL"):
> The Massachusetts instance is currently broken because the ownerdaemon
> is broken.  So I am going to update the owner and queue daemons, and
> restart everything, and then remove the Mass stop file.

The Mass owner daemon did not start because it runs on the DB VM which:
  * Did not have /home/osstest/.xen-osstest/settings
  * Did not have libhtml-parser-perl installed
I have sorted this out.

> The Cambridge instance doesn't have the SQL locking changes yet, but
> it would start testing the new osstest which might start to cause
> trouble.  So I have dropped a stop file there now.  When Cambridge has
> drained, probably tomorrow, I will update the daemons there (but not
> push anything to the main in-use trees).
> 
> Any other instances (eg, Intel?) running in Executive mode need to get
> the updates to the owner and queue daemons before starting to use the
> new osstest.git for actual test flights.

Ian.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL
  2015-12-15 17:20       ` Ian Jackson
@ 2015-12-16  1:39         ` Robert Hu
  0 siblings, 0 replies; 13+ messages in thread
From: Robert Hu @ 2015-12-16  1:39 UTC (permalink / raw)
  To: Ian Jackson; +Cc: xen-devel, Ian Campbell, robert.hu

On Tue, 2015-12-15 at 17:20 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL"):
> > The Massachusetts instance is currently broken because the ownerdaemon
> > is broken.  So I am going to update the owner and queue daemons, and
> > restart everything, and then remove the Mass stop file.
> 
> The Mass owner daemon did not start because it runs on the DB VM which:
>   * Did not have /home/osstest/.xen-osstest/settings
>   * Did not have libhtml-parser-perl installed
> I have sorted this out.
> 
> > The Cambridge instance doesn't have the SQL locking changes yet, but
> > it would start testing the new osstest which might start to cause
> > trouble.  So I have dropped a stop file there now.  When Cambridge has
> > drained, probably tomorrow, I will update the daemons there (but not
> > push anything to the main in-use trees).
> > 
> > Any other instances (eg, Intel?) running in Executive mode need to get
> > the updates to the owner and queue daemons before starting to use the
> > new osstest.git for actual test flights.

Thanks for your care, Ian. My side instances only run in Standalone
mode.

> 
> Ian.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2015-12-16  1:33 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-15 16:26 [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Jackson
2015-12-15 16:26 ` [OSSTEST PATCH 2/4] Database locking: Perl: Increase retry count Ian Jackson
2015-12-15 16:33   ` Ian Campbell
2015-12-15 16:26 ` [OSSTEST PATCH 3/4] Database locking: Tcl: Cover LOCK TABLEs with catch Ian Jackson
2015-12-15 16:34   ` Ian Campbell
2015-12-15 16:26 ` [OSSTEST PATCH 4/4] Database locking: Tcl: Limit number of retries Ian Jackson
2015-12-15 16:35   ` Ian Campbell
2015-12-15 16:33 ` [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL Ian Campbell
2015-12-15 16:41   ` Ian Jackson
2015-12-15 16:47     ` Ian Campbell
2015-12-15 17:01     ` Ian Jackson
2015-12-15 17:20       ` Ian Jackson
2015-12-16  1:39         ` Robert Hu

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.