RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date
Msg-id OSCPR01MB149662AEA64F4E66F494C2584F5E3A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  ("Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>)
Responses Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
List pgsql-hackers
Dear Iwata-san,

>Background
>==========
>If the background workers connect to databases, some database-related commands
>like ALTER DATABASE RENAME and ALTER DATABASE SET TABLESPACE cannot be done.
>Users must do DROP EXTENSION related with workers, or terminate them by themselves
>if they want to drop or alter the database.
>
>Proposal
>========
>Based on above, I would like to propose to terminate background workers automatically
>when such SQLs are executed.
 >
>This feature allows the DBMS daemon to send a termination signal to background workers
>created by users currently operating on the database when executing commands that make
>significant changes to the database.

Per my understanding, we already have a facility that terminates a background
worker, TerminateBackgroundWorker(). So, I'm afraid your proposal has already
been done by combining this function and ProcessUtility_hook.

So, is the main benefit of the patch to shorten extensions codes which uses
bgworker?

Best regards,
Hayato Kuroda
FUJITSU LIMITED




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Should we update the random_page_cost default value?
Next
From: Michael Paquier
Date:
Subject: Re: Refactoring: Use soft error reporting for *_opt_error functions