Re: failures in t/031_recovery_conflict.pl on CI
От | Tom Lane |
---|---|
Тема | Re: failures in t/031_recovery_conflict.pl on CI |
Дата | |
Msg-id | 2823814.1651808182@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: failures in t/031_recovery_conflict.pl on CI (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: failures in t/031_recovery_conflict.pl on CI
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.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. While I'd certainly support back-patching that functionality, I think we need to have a discussion about how to do it. I wonder whether we shouldn't drop src/test/perl/PostgreSQL/... into the back branches in toto and make the old test APIs into a wrapper around the new ones instead of vice versa. But that's definitely not a task to undertake three days before a release deadline. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: