Re: Online enable/disable data checksums functions return success even when the launcher fails to start

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Online enable/disable data checksums functions return success even when the launcher fails to start
Date: 2026-08-30 20:14:17
Message-ID: 4AEB565D-5E7F-4D36-87E3-3F9AE6B7CD5D@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 29 Aug 2026, at 07:09, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:

> In the best case, waiting for the background worker to
> start is very short, and if any failure is detected in forking the
> worker, these functions error out (similar to
> apw_start_leader_worker()).

It may be short (for some value of) in best case, but my concern is that it
will in every case be impossible to determine in what timeframe it will return.
It's also not replacing any bit of monitoring required. Also, this is just the
launcher, and gives no insight into the workers doing the actual heavy lifting.

> I still think this needs to be tightened in PG19 as well, but I'm fine with
> HEAD only.

Every bit of behavioural change is out of scope for v19 IMO, we are post beta3
and should only fix bugs and regressions. Pursuing it for v20 is another thing
of course, so I would recommend registering in the commitfest and someone else
might think I'm completely wrong, which is fine.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-30 20:15:27 Re: Changing the state of data checksums in a running cluster
Previous Message Ayush Tiwari 2026-08-30 20:05:39 Concurrent DROP TABLESPACE can miss a shared dependency