Contingency mechanism: Fedora Modules available

How do we plan to use this contingency mechanism if packages in nonmodular Fedora are broken by the update? Do I read it as "if there are significant problems, we'll revert the change and users can opt in for postgres 12 from modules" or as "if there are significant problems, we'll keep the change and users can opt out from postgres 12 using any other alternate version from modules"?

Based on the description of changes, this should be a straightforward upgrade in most cases. So I'm not too worried about just updating the version in rawhide at some point.

I think the contingency plan would be easier to reason about (and in particular to be able to pin down all the details), if postgres 11 was provided as a "compat package" postgres11, that would have Conflicts:postgres. That way, if we discover that some packages (or some user use cases outside of packaging) do not work with postgres12, they can easily declare dependencies on postgresql11-server. The motivation to prefer that over a module is that modules are not easily upgradeable in F32, and we don't even know how they will look in F33+. Non-modular packages can easily declare the dependency on a compat package. We know how to do the eventual upgrade or obsoletion of postgres11. And postresql is just one package, so building a "compat package" is not particularly onerous.

That said, if maintainers prefer to go the module route for the non-default version, that is OK too.

The "Upgrade/compatibility impact" and "User Experience" section has me extremely nervous at the moment. The upgrade process requires a manual step (postgresql-setup --upgrade) that means that this will not be a smooth transition for most users.

I'd like to see this section fleshed out in far greater detail before I would vote to approve. (So I'm putting a -1 vote on this for now.)

@sgallagh The postgresql-setup --upgrade has always needed to be run in previous major rebases and we got no negative feedback about this. IOW, users do it for years already, I'm convinced users prefer manipulating data themselves and do it deliberately after OS upgrade. It was never done automatically in case of PostgreSQL. I don't think we need to do it differently this time.

Edit: We should properly document this in the Release notes though.

@zbyszek @churchyard I kinda like the @churchyard's wording, "if there are significant problems, we'll revert the change and users can opt in for postgres 12 from modules". I think it was meant this way. @panovotn, please, confirm and edit the proposal.

@hhorak @churchyard I like the @churchyard's wording as well, and I hope you don't mind that I've used it.

The change page has been updated with a more descriptive contingency plan statement.

Thank You. For the reference: https://fedoraproject.org/w/index.php?title=Changes%2FPostgreSQL_12&type=revision&diff=565496&oldid=565049

I'm +1.

+1

@sgallagh, let us know if you have any suggestion what we can do differently/better, to make you feel ok with this proposal :)

I realize this is "how we have always done it", but that doesn't mean it was a good idea then, either :smile:

Honestly, PostgreSQL is a perfect example of something that really shouldn't upgrade automatically across releases. It's not compatible and unless you upgrade your entire cluster of replicas at the same time, you're going to have problems.

What I would rather see is for us to standardize on an approach where users never switch major versions unless they request it. One such approach would be to switch PostgreSQL to be modular-only. Another would be to ship major-versioned compat packages.

If those aren't acceptable for various reasons (maintenance burden, etc.) then I'd like to see at least some assertions that the postgresql service would fail to start with a loud message in the logs about why and what users need to do to resolve it.

Tagged with meeting, the votes are +2, 0, -1 after a week.

@sgallagh Thanks for the feedback.

Starting from the last comment -- the message is there in the logs, so the experience actually is (when upgrading from postgresql v11 to v12): the service does not start and it instructs the user to run postgresql-setup --upgrade:

Feb 07 11:53:16 <host> postgresql-check-db-dir[16284]: An old version of the database format was found.
Feb 07 11:53:16 <host> postgresql-check-db-dir[16284]: Use 'postgresql-setup --upgrade' to upgrade to version '11'
Feb 07 11:53:16 <host> postgresql-check-db-dir[16284]: See /usr/share/doc/postgresql/README.rpm-dist for more information.

Mind, that we also need to package the previous version to make this work, because the upgrading process needs the daemon from previous version. So, in short, we've already gone the extra mile in this regard at least a bit. Any improvements suggestions are welcome.

For the idea of staying with a modular build when the user is not ready yet -- I totally agree here, that users should be able to switch the DB version no matter when they switch the OS version. I don't think there is a mechanism to let the "upgrade tool" know that it should or should not enable a module during upgrade, and also it is probably not a behaviour that everybody wants the same. So, the current answer for not upgrading the DB during OS upgrade is that we have probably two ways:

• user can switch to modular build before upgrade, then run upgrade
• use can upgrade, then enable previous version, and downgrade the packages

Surprisingly, both cases turned to be done by the same command:
dnf -y module enable postgresql:11 && dnf -y distro-sync postgresql\*

Similarly, a user might want to upgrade postgresql first, and then do the OS upgrade, which is also available:
dnf -y module enable postgresql:12 && dnf -y distro-sync postgresql\*

Does this sound like we should document it and be happy?

Does this sound like we should document it and be happy?

That covers all of my concerns. +1

That makes it APPROVED (+3, 0, -0)

Thanks folks for the feedback.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z5N6Z6TL5MI6UICFG6RXCPCKU3UFYALJ/