Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE

On Mon, Nov 09, 2026 at 06:49:41PM +0800, Xuneng Zhou wrote:
> There seems to be a risk of interpreting the exit of worker & its PID
> reuse as non-exit failure here. How about adding a new critera like
> process start time for checking that as V4 does.

I'm finding this addition utterly esoteric, because this would be hit
yes, but the risk is dramatically low compared to making the test more
complex to parse. v3 as sent by Zsolt is just but fine to me.

+ The old worker is known to have exited, so do not
+# rely on the PID of the new worker being different, as it could be reused.

This last sentence should be gone. There is no point in sticking
comments for things that are non-conditions to begin with. This was
clearly AI-generated, as the kind of things that agents like adding
for nothing based on solely the input provided..

+ The worker is then restarted or unregistered as after any other exit,
+ depending on its exit code and <structfield>bgw_restart_time</structfield>.

Okay, fine.

- <command>CREATE DATABASE</command>. Specifically, the postmaster sends a
- termination signal when any of these commands affect the worker's database:
+ <command>CREATE DATABASE</command>. Specifically, a termination signal is
+ sent when any of these commands affect the worker's database:

That's a good addition.
--
Michael