Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Дата
Msg-id 3074140.1775074810@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  (Alexander Lakhin <exclusion@gmail.com>)
Ответы RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Список pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes:
> I think this can explain slow CommitTransactionCommand() and why it
> happens not every time. Regarding other animals, I guess they can
> experience the same bumps but not exceeding 5 seconds (50 tries). Thus,
> from my understanding, for the failure to happen, we need to have slow
> storage and initialize_worker_spi() -> CommitTransactionCommand() reaching
> XLogFileClose().

So, it remains not very clear why only widowbird is showing this
failure, but I think we can safely take away the bottom-line
conclusion that hard-wiring a maximum wait of 5s in
CountOtherDBBackends() was not a great idea.

I don't think I want to propose a GUC for this, but could it make
sense to check for an environment variable, similarly to PGCTLTIMEOUT
and PG_TEST_TIMEOUT_DEFAULT?  Whichever way we do it, it could replace
the existing crude hack to change the max wait in injection-point
mode.

            regards, tom lane



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