| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-03-31 10:54:30 |
| Message-ID: | acun5kN_JaLFcfq_@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 31, 2026 at 10:00:00AM +0300, Alexander Lakhin wrote:
> So the backend is not completely stuck, but CommitTransactionCommand()
> may take more than 5 seconds under some circumstances (maybe it's worth
> investigating which exactly).
One could blame slow hardware, difficult to say, and I'm puzzled by
these periodic bumps that don't seem to happen elsewhere. There is at
least one alternative that I can think here to make the test more
stable and make sure that worker_spi reaches its main loop before
attempting the database commands. We could add a wait_for_event() at
the end of launch_bgworker() based on WorkerSpiMain, and enlarge
worker_spi_naptime to an insanely larger value, to make sure that we
remain on the WaitLatch() until the worker is interrupted and that we
don't attempt a new transaction.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Junwang Zhao | 2026-03-31 10:57:46 | Re: Eliminating SPI / SQL from some RI triggers - take 3 |
| Previous Message | Amit Kapila | 2026-03-31 10:47:18 | Re: Adding REPACK [concurrently] |