Re: pg_rewind tap test unstable
От | Michael Paquier |
---|---|
Тема | Re: pg_rewind tap test unstable |
Дата | |
Msg-id | CAB7nPqQY3ehhT9PBpnnYQtWar=3MKHn7eYqdTDERnAFZ=oS4xA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_rewind tap test unstable (Christoph Berg <myon@debian.org>) |
Ответы |
Re: pg_rewind tap test unstable
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: