Re: Introduce wait_for_subscription_sync for TAP tests

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Introduce wait_for_subscription_sync for TAP tests
Дата
Msg-id 254218.1662759943@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Introduce wait_for_subscription_sync for TAP tests  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Introduce wait_for_subscription_sync for TAP tests
Re: Introduce wait_for_subscription_sync for TAP tests
Список pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Fri, Sep 9, 2022 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Recently a number of buildfarm animals have failed at the same
>> place in src/test/subscription/t/100_bugs.pl [1][2][3][4]:
>> 
>> #   Failed test '2x3000 rows in t'
>> #   at t/100_bugs.pl line 149.
>> #          got: '9000'
>> #     expected: '6000'
>> # Looks like you failed 1 test of 7.
>> [09:30:56] t/100_bugs.pl ......................
>> 
>> This was the last commit to touch that test script.  I'm thinking
>> maybe it wasn't adjusted quite correctly?  On the other hand, since
>> I can't find any similar failures before the last 48 hours, maybe
>> there is some other more-recent commit to blame.  Anyway, something
>> is wrong there.

> It seems that this commit is innocent as it changed only how to wait.

Yeah.  I was wondering if it caused us to fail to wait somewhere,
but I concur that's not all that likely.

> It's likely that the commit f6c5edb8abcac04eb3eac6da356e59d399b2bcef
> is relevant.

Noting that the errors have only appeared in the past couple of
days, I'm now suspicious of adb466150b44d1eaf43a2d22f58ff4c545a0ed3f
(Fix recovery_prefetch with low maintenance_io_concurrency).

            regards, tom lane



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

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: Avoid overhead with fprintf related functions
Следующее
От: Ranier Vilela
Дата:
Сообщение: Re: Avoid overhead with fprintf related functions