Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Дата
Msg-id 20211214061449.ynrygtcddn3ujunn@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 2021-12-14 14:31:24 +0900, Michael Paquier wrote:
> On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> > Seems like we might get away with making make -C contrib/pg_upgrade check and
> > vcregress.pl upgradecheck do nothing?
> 
> You mean #contrib/#src/bin/# here, right?  I don't think that we have
> any need to have "make -C" do nothing.  For vcregress.pl, we should
> IMO just remove upgradecheck.

Tom's point was that the buildfarm scripts do
    if ($self->{bfconf}->{using_msvc})
        @checklog = run_log("perl vcregress.pl upgradecheck");
    else
              "cd $self->{pgsql}/src/bin/pg_upgrade && $make $instflags check";

if we don't want to break every buildfarm member that has TestUpgrade enabled
the moment this is committed, we need to have a backward compat path.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Commitfest 2021-11 Patch Triage - Part 3