Re: [HACKERS] frogmouth failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] frogmouth failures
Date
Msg-id 12104.1493325035@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] frogmouth failures  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] frogmouth failures  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: [HACKERS] frogmouth failures  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Unportable implementation of background worker start