On Mon, Aug 3, 2015 at 5:35 PM, Christoph Berg <myon@debian.org> wrote:
> Re: Michael Paquier 2015-07-28 <CAB7nPqQCpGy3u7CMfo8sQQUoBSFmEieOhuEsLxwyCC64j3GWxQ@mail.gmail.com>
>> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg <myon@debian.org> wrote:
>> > for something between 10% and 20% of the devel builds for apt.postgresql.org
>> > (which happen every 6h if there's a git change, so it happens every few days),
>> > I'm seeing this:
>> > Dubious, test returned 1 (wstat 256, 0x100)
>> > Failed 1/8 subtests
>> >
>> > I don't have the older logs available, but from memory, the subtest
>> > failing and the two numbers mentioned are always the same.
>>
>> There should be some output logs in src/bin/pg_rewind/tmp_check/log/*?
>> Could you attach them here if you have them? That would be helpful to
>> understand what is happening.
>
> It took me a few attempts to tell the build environment to save a copy
> on failure and not shred everything right away. So here we go:
In test case 2, the failure happens to be that the standby did not
have the time to replicate the database beforepromotion that has been
created on the master. One possible explanation for this failure is
that the standby has been promoted before all the WAL needed for the
tests has been replayed, hence we had better be sure that the
replay_location of the standby matches pg_current_xlog_location()
before promotion. On the buildfarm, hamster, the legendary slowest
machine of the whole set, does not complain about that. Is your
environment that heavy loaded when you run the tests?
Perhaps the attached patch helps?
--
Michael