frogmouth failures

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&amp;dt=2017-04-27%2018%3A10%3A08&gt;
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&amp;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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/27/2017 04:30 PM, Tom Lane wrote:

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&amp;dt=2017-04-27%2018%3A10%3A08&gt;
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&amp;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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-04-27 16:30:35 -0400, Tom Lane wrote:

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.

Same here. Over the years there've been a number of bug reports with
the same error code, so it's not necessarily specific to master. Could
just be a question of backend spawn rate or such.

- Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers