From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [OSSTEST PATCH 05/27] standalone: Set very long SQLite3 busy timeout in Perl Date: Wed, 16 Sep 2015 14:49:17 +0100 Message-ID: <1442411357.18856.70.camel@citrix.com> References: <1442410530-9665-1-git-send-email-ian.jackson@eu.citrix.com> <1442410530-9665-6-git-send-email-ian.jackson@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZcD5O-0007CH-Fi for xen-devel@lists.xenproject.org; Wed, 16 Sep 2015 13:49:22 +0000 In-Reply-To: <1442410530-9665-6-git-send-email-ian.jackson@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Wed, 2015-09-16 at 14:35 +0100, Ian Jackson wrote: > Without this, big standalone-generate-dump-flight-runvars jobs may > trying to serialise so much work that SQLite3 times out. And we are > about to introduce an optimisation which makes this much more likely. > > In standalone mode we probably don't care much about this timeout at > all. (It might even be that the user is using sqlite(3) and has > effectively locked the database interactively for an extended period.) > > We would prefer to rely on the user to stop anything that seems to > have become stuck. So set the timeout to 10ks. > > Signed-off-by: Ian Jackson Acked-by: Ian Campbell