nixos/postgresql: improve docs on how to upgrade

[Ma27]

Motivation for this change

• It's IMHO a slight overkill to deploy an additional container even if
  it's never supposed to be running. Also, the currently suggested
  approach wouldn't use the default state-directory for the new version.
• Explain the structure of the state-directories and where the
  version-numbers are actually coming from.
• Mention ./analyze_new_cluster.sh & ./delete_old_cluster.sh.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[maralorn]

Oh, nice!

Can you maybe make explicit in which directory to run the two scripts at the end?

I really wished we could make this still easier to deploy for users. e.g. have a pkg.postgres_12_to_13_migration to install? We can probably auto-generate those from the versions of the available postgres packages?

[Ma27]

Can you maybe make explicit in which directory to run the two scripts at the end?

Good idea, will do! :)

I really wished we could make this still easier to deploy for users. e.g. have a pkg.postgres_12_to_13_migration to install? We can probably auto-generate those from the versions of the available postgres packages?

Considering that this is a highly imperative step that can cause a lot of problems if done wrong, I'd like administrators to actually think twice about it before doing that.

Also, there's way too much stuff someone has to take care of on their own:

• stopping - if needed - services writing to the database
• which datadir to use (you can still override services.postgresql.dataDir)

All in all, I think we'd have to assume too much when implementing that.

[maralorn]

Fair.

Also, there's way too much stuff someone has to take care of on their own:

* stopping - if needed - services writing to the database

* which datadir to use (you can still override `services.postgresql.dataDir`)

Those are good points, maybe also mention them in the explanation?^^

Not a must though.

[Ma27]

@maralorn updated accordingly :)

[maralorn]

Thx!