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

From: "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>
To: 'Peter Smith' <smithpb2250(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date: 2026-01-05 15:06:53
Message-ID: OS7PR01MB1196426354C0294148A06AC65EA86A@OS7PR01MB11964.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

Thank you for your comments and suggestions on the previous version patches!
I believe this feature become much better.

I've created a v13 patch incorporating Peter-san's suggestions.

> One issue with the test as written, as of run_db_command(), is that we
> make sure that a worker is stopped by scanning the output of the logs.
> This approach may detect incorrect patterns, unfortunately. For
> example, if the termination logic has a bug it may be possible that
> the worker found as terminated is the first one created by the test,
> which we expect to always run. While the log is mandatory to have, I
> have a suggestion to make that even better: let's keep track in
> run_db_command() of the PIDs of the worker processes we expect to
> exist after running each database command, then make sure that the
> list of PIDs match with what we expect. This is a bit simpler in the
> case of this test as we only expect one matching PID.

I've also reviewed the test set code comparing PIDs. I think this is acceptable.

Best Regards,
Aya Iwata

Attachment Content-Type Size
v0013-0001-Allow-background-workers-to-be-terminated-at-D.patch application/octet-stream 15.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2026-01-05 15:08:40 Re: PL/Python initialization cleanup
Previous Message vignesh C 2026-01-05 15:02:57 Re: Proposal: Conflict log history table for Logical Replication