From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: failures in t/031_recovery_conflict.pl on CI |
Date: | 2022-05-06 03:53:20 |
Message-ID: | 20220506035320.db77mag7nahxzpyy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-05-05 23:36:22 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2022-05-05 22:07:40 -0400, Tom Lane wrote:
> >> May I ask where we're at on this? Next week's back-branch release is
> >> getting uncomfortably close, and I'm still seeing various buildfarm
> >> animals erratically failing on 031_recovery_conflict.pl.
>
> > Looks like the problems are gone on HEAD at least.
>
> It does look that way, although the number of successes is not large yet.
>
> >> Should we just remove that test from the back branches for now?
>
> > That might be the best course, marking the test as TODO perhaps?
>
> I poked closer and saw that you reverted 5136967f1 et al because
> (I suppose) adjust_conf is not there in the back branches.
Yea. That one was a stupid mistake, working outside my usual environment. It's
easy enough to work around adjust_conf not existing (just appending works),
but then there's subsequent test failures...
> So I reluctantly vote for removing 031_recovery_conflict.pl in the
> back branches for now, with the expectation that we'll fix the
> infrastructure and put it back after the current release round
> is done.
What about instead marking the flapping test TODO? That'd still give us most
of the coverage...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-06 03:57:28 | Re: failures in t/031_recovery_conflict.pl on CI |
Previous Message | Tom Lane | 2022-05-06 03:36:22 | Re: failures in t/031_recovery_conflict.pl on CI |