| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Iwata, Aya/岩田 彩 <iwata(dot)aya(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Kuroda, Hayato/黒田 隼人 <kuroda(dot)hayato(at)fujitsu(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE |
| Date: | 2026-04-01 20:20:10 |
| Message-ID: | 3074140.1775074810@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Lakhin <exclusion(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Corey Huinker | 2026-04-01 20:07:49 | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions |