Re: fairywren hung in pg_basebackup tests

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: fairywren hung in pg_basebackup tests
Дата
Msg-id 20220726045347.GA3528716@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: fairywren hung in pg_basebackup tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jul 25, 2022 at 11:35:12AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Mon, Jul 25, 2022 at 09:44:21AM -0400, Andrew Dunstan wrote:
> >> Perhaps we should have a guard in system_or_bail() and/or system_log()
> >> which bails if some element of @_ is undefined.
> 
> +1, seeing how hard this is to diagnose.
> 
> > That would be reasonable.  Also reasonable to impose some long timeout, maybe
> > 10x or 100x PG_TEST_TIMEOUT_DEFAULT, on calls to those functions.
> 
> Why would it need to be more than PG_TEST_TIMEOUT_DEFAULT?

We run some long commands, like the parallel_schedule runs.  Those currently
use plain system(), but they probably should have used system_log() from a
logging standpoint.  If they had, PG_TEST_TIMEOUT_DEFAULT would have been too
short.  One could argue that anything that slow should declare its intent to
be that slow, but that argument is getting into the territory of a policy
change rather than a backstop for clearly-unintended longevity.



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Introduce wait_for_subscription_sync for TAP tests