Re: frogmouth failures

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: frogmouth failures
Date: 2017-04-27 20:40:07
Message-ID: 8f8671ea-b9d6-6bcc-4f64-75948279dd18@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/27/2017 04:30 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> I've been trying to track down the cause of recent failures at the "make
>> check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
> I've been wondering about that too.
>
>> Then I tried running (offline mode) the serial schedule instead of the
>> parallel schedule, and it went through with no error. So then I tried
>> setting MAX_CONNECTIONS=10 and that also worked - see
>> <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogmouth&dt=2017-04-27%2018%3A10%3A08>
>> I've reverted that setting, but if errors start to occur again we'll
>> have some slight notion of where to look.
> Judging by the recent history,
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=frogmouth&br=HEAD
> it's not 100% reproducible. (Either that, or we un-broke it and re-broke
> it within the last week, which seems improbable.) So unless you made
> quite a few successful runs with the lower MAX_CONNECTIONS setting,
> I'm dubious that there's really a connection.
>
> Having said that, I won't be a bit surprised if it is some sort of
> parallelism effect. I just don't think one test proves much.
>

I'll leave it on for a week and then remove it, that should give us a larger sample.

cheers

andrew

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-27 20:40:59 Re: frogmouth failures
Previous Message Tom Lane 2017-04-27 20:35:29 Re: Unportable implementation of background worker start