Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frxHs-0000cS-3W for buildfarm-members@arkaria.postgresql.org; Tue, 21 Aug 2018 03:24:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1frxHo-0001Fa-Ed for buildfarm-members@arkaria.postgresql.org; Tue, 21 Aug 2018 03:24:52 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frxHn-0001FM-Un for buildfarm-members@lists.postgresql.org; Tue, 21 Aug 2018 03:24:52 +0000 Received: from mail-pl0-x234.google.com ([2607:f8b0:400e:c01::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1frxHh-0002v2-2r for buildfarm-members@postgresql.org; Tue, 21 Aug 2018 03:24:50 +0000 Received: by mail-pl0-x234.google.com with SMTP id g23-v6so5126975plq.9 for ; Mon, 20 Aug 2018 20:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=a20NhHL8JwpiRlubL4JHUu2nH1/G1fiQA2goP/WLnIE=; b=BFYch6a0IsV+FG4/IFd91ha/T7S4GDfDLOK1baLNUUJe2i7bScgahb6+it0ZH1yiLT hF+XoedTM096WLKN7ANTAxvslDrRTlefU0KOjp5nwT5pze3zkj/0ck0qOxb9A7WrFGl1 BqqN25/FsQTGeIh7vs3bnLozFweotfWrcIn4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=a20NhHL8JwpiRlubL4JHUu2nH1/G1fiQA2goP/WLnIE=; b=FyPwPwgpn9ZlSwC/CnPFY1gYcuTISNXohll3yA14feuHjYZU0Ilm3j/x+GC8+eqB5l hyAmPow3SDpjUY8gB/voYkMr7oII1kH/l9PjwNlVmw0iqbjiIwPPc+ZycZ0b0rzxvozJ fKLlhuwdshXEjmB8GXdrF1am+11QdNT7bOqgCseReyTESEpDz4VE7kw4Yf7F64hZ7xy2 7lcAsMbjLPyRkA+Ocx4IrgB+ohFFDtP5j2HZCgLwdh5P5lp54bdAwBfTsiZIwynDwrFa cAtfkVsPm2qbk2fE+q1H2W0Tpc/GRVCI26FckoyZDSaSIVOqoT4BY3wWlx9PEXXXvzGr MB8A== X-Gm-Message-State: AOUpUlHwD4KQR+oUPb9gsGSj7EyrD0TUYgEAWn0ssa5AWu7FOK51mY4A CiQ2JD5QRywyeru35sJmmmAPCA== X-Google-Smtp-Source: AA+uWPzkzTumTGHoAmJ41FlDjh4Tq1Xmgc6/XcS+kx17W49eoP25xJabX2tI27fm67ydnJAh3cpg4w== X-Received: by 2002:a17:902:a713:: with SMTP id w19-v6mr47298637plq.271.1534821883722; Mon, 20 Aug 2018 20:24:43 -0700 (PDT) Received: from rfd.leadboat.com (c-73-158-248-138.hsd1.ca.comcast.net. [73.158.248.138]) by smtp.gmail.com with ESMTPSA id r81-v6sm16097243pfa.18.2018.08.20.20.24.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 20:24:42 -0700 (PDT) Date: Mon, 20 Aug 2018 20:24:40 -0700 From: Noah Misch To: Andrew Dunstan Cc: buildfarm-members@postgresql.org Subject: Re: many animals are running old clients Message-ID: <20180821032440.GA217087@rfd.leadboat.com> References: <144264ec-fd45-80eb-7642-109f920286b9@2ndQuadrant.com> <20180818070030.GA3795674@rfd.leadboat.com> <20180818162211.GC3795674@rfd.leadboat.com> <966eeb24-3f37-29da-dee2-91522bbe1850@2ndQuadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <966eeb24-3f37-29da-dee2-91522bbe1850@2ndQuadrant.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Aug 19, 2018 at 03:04:58PM -0400, Andrew Dunstan wrote: > On 08/18/2018 12:22 PM, Noah Misch wrote (offlist): > >On Sat, Aug 18, 2018 at 08:17:17AM -0400, Andrew Dunstan wrote: > >>Is there anything I can do to make upgrade easier? > >The show_log.pl web page could highlight a particular run's config change, > >including version number changes, when there is such a change compared to the > >previous run. If it's clear enough that folks are unlikely to confuse an > >upgrade-induced failure with a PG-commit-induced failure, I could stop checking > >for post-upgrade buildfarm failures. > > What I've done is add this to the database in a way that makes it easily > accessible to the web app, and added that info to the history page. I think that wastes prime screen real estate. If show_history.pl is going to spend that space on something, I would choose commit hash. But I liked it better with nothing there. The concept I had in mind was a "Config changed since last success" block adjacent to the "Files changed since last success" block in show_log.pl. It might look like this: - 'config_env' => { 'CC' => 'gcc' }, + 'config_env' => { 'CC' => 'gcc -mips32r2' }, - 'script_version' => 'REL_7', + 'script_version' => 'REL_8', Script version is a minor aspect, worth little by itself. If you diff the entire config block, though, that amounts to a meaningful feature.