The new postgresql.target will now wait until recovery is done and
read/write connections are possible.
This allows ensure* scripts and downstream migrations to work properly
after recovery from backup.
Resolves#346886
This avoids restarting the postgresql server, when only ensureDatabases
or ensureUsers have been changed. It will also allow to properly wait
for recovery to finish later.
To wait for "postgresql is ready" in other services, we now provide a
postgresql.target.
Resolves#400018
Co-authored-by: Marcel <me@m4rc3l.de>
This will allow dropping the linuxPackages_ham variant. Fedora sets
these in their default kernel, so I don't anticipate any problem with
us doing the same.
Tested building linux_5_4, linux, and linux_latest on x86_64.
Kernel 6.16-rc1 removed the poly1305 algorithm in
ceef731b0e22df80a13d67773ae9afd55a971f9e
bcachefs switched to the kernel libraries for poly1305 and chacha20 in
6.15 in 4bf4b5046de0ef7f9dc50f3a9ef8a6dcda178a6d
From systemd-repart(8):
If not specified it is attempted to read the machine ID from the host
(or more precisely, the root directory configured via --root=) and use
it as seed instead, falling back to a randomized seed otherwise. Use
--seed=random to force a randomized seed.
The option documentation now suggests the special value "random", for
a random seed rather than relying on the implicit fact that there is
no machine ID available in the build sandbox, causing repart to fallback
on generating a random seed.
Fixes#419331
`config.services.postgresql.package` is now only available when the
PostgreSQL module is actually enabled. If we're not using the local
database, we'll need to fallback to the latest postgresql version, since
we don't know about the remote version.
`config.services.postgresql.package` is now only available when the
PostgreSQL module is actually enabled. If we're not using the local
database, we'll need to fallback to the latest postgresql version, since
we don't know about the remote version.
