public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Dunstan <[email protected]>
To: Noah Misch <[email protected]>
Cc: [email protected]
Subject: Re: many animals are running old clients
Date: Tue, 21 Aug 2018 06:58:01 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>



On 08/20/2018 11:24 PM, Noah Misch wrote:
> 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.


It's easy to revert the display change, and there is utility in having 
the script version easily available in the database without having to 
extract it in each query.

Getting the config summary from the previous build is possibly a bit 
less simple.

I'll take a look when I get a bit more time.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: many animals are running old clients
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox