fix postgres tests and remove eol postgresql12

[laalsaas]

Since postgresql sets ProtectSystem=strict, all directories must exist before the service is started. Also all directories where write access is needed must be specified.

PL-133170

@flyingcircusio/release-managers

Release process

• Created changelog entry using ./changelog.sh

PR release workflow (internal)

• PR has internal ticket
• internal issue ID (PL-…) part of branch name
• internal issue ID mentioned in PR description text
• ticket is on Platform agile board
• ticket state set to Pull request ready
• if ticket is more urgent than within the next few days, directly contact a member of the Platform team

Design notes

• Provide a feature toggle if the change might need to be adjusted/reverted quickly depending on context. Consider whether the default should be on or off. Example: rate limiting.
• All customer-facing features and (NixOS) options need to be discoverable from documentation. Add or update relevant documentation such that hosted and guided customers can understand it as well.

Security implications

• Security requirements defined? (WHERE)
  • we need the postgresql test to pass.
  • we have to run supported software versions
• Security requirements tested? (EVIDENCE)
  • the postgresql test passes now
  • postgresql12 is now removed as it's eol

[laalsaas]

to me, this raises the question, why exactly we are setting gcroots „manually“ and if we really need to do that. maybe @dpausp can provide some insight here.

[osnyx]

This is done to keep around old postgresql versions during postgres updates. At start, each postgres verrsion registers itself in the postStart phase as a gcroot. Our fc-postgresql tooling cleans these gcroots after a successful update.

[osnyx]

You forgot to remove the postgres12-related entries from important packages as well, I just added that to mitigate eval errors in a more recent nixpkgs.

[osnyx]

This is done to keep around old postgresql versions during postgres updates. At start, each postgres verrsion registers itself in the postStart phase as a gcroot. Our fc-postgresql tooling cleans these gcroots after a successful update.