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

From: "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>
To: 'Michael Paquier' <michael(at)paquier(dot)xyz>
Cc: 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>, Peter Smith <smithpb2250(at)gmail(dot)com>
Subject: RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date: 2025-12-24 08:42:51
Message-ID: OS7PR01MB11964D713C79B209EFF6A024CEAB2A@OS7PR01MB11964.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

> FWIW, while reading this code, I was wondering about one improvement
> that could show benefits for more extension code than only what we are
> discussing here because external code has no access to
> BackgroundWorkerSlot while holding the LWLock BackgroundWorkerLock in
> a single loop, by rewriting this new routine with something like that:
> void TerminateBackgroundWorkerMatchin(
> bool (*do_terminate) (int pid, BackgroundWorker *, Datum))
>
> Then the per-database termination would be a custom routine, defined
> also in bgworker.c. Other extension code could define their own
> filtering callback routine. Just an idea in passing, to let extension
> code take more actions on bgworker slots in use-based on a PGPROC
> entry, like a role ID for example, or it could be a different factor.
> Feel free to dislike such a funky idea if you do not like it and say
> so, of course.

I'm sorry for the delayed response.
I tried implementing a callback function within the for loop to allow setting the termination
condition myself. However, I felt this method had few use-cases. Since LWlock exists in here, it can
only handle lightweight operations.
Therefore, I'd prefer not to include it at this time. If I later think of a useful scenario for it, I'll
reconsider about this.

Best Regards,
Aya Iwata

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-12-24 08:58:20 Re: Orphaned records in pg_replication_origin_status after subscription drop
Previous Message Zhijie Hou (Fujitsu) 2025-12-24 08:41:58 RE: POC: enable logical decoding when wal_level = 'replica' without a server restart