Hi, I think there may be another case to consider here. DROP DATABASE durably marks the database invalid before it removes the catalog row and files, so a crash or ERROR after the marker is written leaves an invalid row whose files are still present. If checksum enabling is running at the same time, the worker will fail to connect to that database, and since 1df361e3d82 DatabaseExists() returns false for an invalid row. AFAICT the launcher then classifies the failure as a concurrent drop and skips the database, potentially letting data_checksums reach "on" while those files were never processed.
AFAICS nothing else rules this out, so I am attaching a patch along with a TAP test that uses a new injection point in dropdb() to exercise the race directly. The patch makes DatabaseExists() return true for any present row; ISTM that AccessShareLock already waits out an in-flight drop, so an invalid-but-present row can only be from an interrupted one whose files still need checksums. I am not sure if the patch needs a dedicated TAP test, however I've added one. Apologies if this is expected behaviour, and I missed on some thread mentioning it. Regards, Ayush
0001-Don-t-skip-invalid-databases-when-enabling-data-chec.patch
Description: Binary data
