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 по дате отправления: