Re: Tracing down buildfarm "postmaster does not shut down" failures

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Tracing down buildfarm "postmaster does not shut down" failures
Дата
Msg-id 19415.1455048301@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Tracing down buildfarm "postmaster does not shut down" failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Tracing down buildfarm "postmaster does not shut down" failures  (Andrew Dunstan <andrew@dunslane.net>)
Re: Tracing down buildfarm "postmaster does not shut down" failures  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
I wrote:
> In any case, we should proceed with fixing things so that buildfarm owners
> can specify a higher shutdown timeout for especially slow critters.

I looked into doing this as I suggested yesterday, namely modifying the
buildfarm scripts, and soon decided that it would be a mess; there are
too many cases where "pg_ctl stop" is not invoked directly by the script.

I'm now in favor of applying the PGCTLTIMEOUT patch Noah proposed, and
*removing* the two existing hacks in run_build.pl that try to force -t 120.

The only real argument I can see against that approach is that we'd have
to back-patch the PGCTLTIMEOUT patch to all active branches if we want
to stop the buildfarm failures.  We don't usually back-patch feature
additions.  On the other hand, this wouldn't be the first time we've
back-patched something on grounds of helping the buildfarm, so I find
that argument pretty weak.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Multi-tenancy with RLS
Следующее
От: Josh Kupershmidt
Дата:
Сообщение: Re: proposal: make NOTIFY list de-duplication optional