Re: many animals are running old clients

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