Re: datachecksums: handle invalid and dropped databases during enable

Hi,

While checking commit 51f55b13a4d, I noticed a regression in repeated
calls to pg_enable_data_checksums().

Before that commit, calling pg_enable_data_checksums() after checksums had
reached the "on" state succeeded as a no-op. The existing basic TAP test
also documents that behavior.

51f55b13a4d added ErrorOnInvalidDatabases() before
StartDataChecksumsWorkerLauncher(). If an invalid database exists, the
same repeated call now fails even though no database processing is needed:

ERROR: cannot enable data checksums in a cluster with invalid database
"baddb"

The attached v1 patch restores that no-op, but does not use a bare
DataChecksumsOn() early return. Such a return could lose a pending disable
request and violate the existing last-request-wins behavior.

Instead, the patch makes the no-op decision under
DataChecksumsWorkerLock and records the requested enable operation and cost
settings atomically. If a disable operation is already running, it keeps
the invalid-database preflight because the subsequent enable may need to
process every database.

The patch adds two tests. The basic test covers repeated enable with an
invalid database while checksums are on, followed by a real enable from the
off state which must still fail. An injection test pauses an active disable
before the visible state changes from on, and verifies that enable still
checks invalid databases in that case.

Tested on origin/master at
33b392eaabdd1c563d40388784df051821e03c6b:

Unpatched master with the new basic test:
expected FAIL, 1 of 24 tests failed, only the new no-op assertion.

Patched default test_checksums suite:
PASS, 9 files and 95 tests.

Patched extended pgbench, standby, and PITR tests:
PASS, 3 files and 102 tests.

Full build, git diff --check, patch apply check, and Perl syntax:
PASS.

I tested master only. My local REL_19_STABLE ref predates the backpatch of
51f55b13a4d, and I did not refresh it while working offline.

This should be backpatched to v19 together with 51f55b13a4d.

Regards,
Ilmar Yunusov