[jpargudo]

What kind of change does this PR introduce?

• hardening prepare.sh and
• adding 2 features to initiate.sh:
  • taking the upgrade process as an opportunity to add checksums to the projects that don't have it enabled yet (few minutes downtime added)
  • better logging of operations

What is the current behavior?

• prepare.sh was safe since it runs on a newly created VM, with no access except for us. But there was no logs and no "paranoid mode" on operations (stop PostgreSQL, umount /data, etc.)

• initiate.sh

  • wasn't shipping the logs in some corner cases
  • wasn't enabling checksums before the upgrade: hence, an PG database with no checksums in a given version was migrated to the destination of PG without checksums enabled neither.

What is the new behavior?

• prepare.sh has been strongly hardened, probably in "paranoid mode".

initiate.sh now

• ships logs no matter what happens
• enables checksums to projects with a size criteria, so that added operation is a great tradeoff: about 5 minutes for a 20 Gb database. A safeguard is added tho: the operation cannot last more than 10 minutes, otherwise the whole upgrade process will fail.

Notes on pg_checksums

The part around enabling checksums is not meant to survive since in PostgreSQL will one day have checksums enabled on-line with pg_enable_data_checksums() or removed the same way with pg_disable_data_checksums(). Unfortunately this feature was due for PG19, but has been removed from that version. We might then clean the code when PG20 is out, late 2027.

[github-actions]

Package version diff: none (aarch64-linux, x86_64-linux)

[encima]

These failures are happening due to the pre-commit and treefmt. 2 Options:

1. One quick, risky fix is to ask Copilot to resolve these
2. Run nix develop --command pre-commit run --from-ref develop --to-ref HEAD and this will run the pre-commit checks for this branch so you can see and act on the failures.

We will go through these in a call today. It can be tedious but clicking through the job failures will show you which commands failed (it is only a few because the other failures are due to skips or the initial failures)

I did apply all of your last comments, that I did resolve, and applied to 2 patches.
Thank you !!