| 10 Nov 2023 |
 @julienmalka:matrix.org | Currently if we remove the ensure* options a lot of nixos modules are going to be broken no ? | 19:23:47 |
 raitobezarius | In reply to @julienmalka:matrix.org
I we reverted the default postgresql version to 14, the impacted users would be everyone that run nixos-unstable right ? Let's assume we do this | 19:52:41 |
| raitobezarius | We would break anyone PGSQL 15 deployment | 19:52:46 |
| raitobezarius | Because you have to downgrade the PG15 folder now | 19:52:53 |
| raitobezarius | In reply to @julienmalka:matrix.org
What if we remove the default value for postgresql, forcing users to be mindful about the versions they use ? Migrated users could then use version 15 and new users version 14. We would have to also have an assert that ensure* is used only with version 14. This is orthogonal to the situation | 19:53:01 |
| raitobezarius | In reply to @julienmalka:matrix.org
Currently if we remove the ensure* options a lot of nixos modules are going to be broken no ? No, because the modules are migrated in the PR | 19:53:07 |
| raitobezarius | Only out of tree modules would be broken | 19:53:12 |
| raitobezarius | I don't know if the cost of breaking everyone on PG15 is higher or lower than the cost of breaking every out of tree modules with ensurePermission options | 19:55:41 |
| raitobezarius | My view is that the former has higher cost because I don't think a lot of people understand well PostgreSQL to understand how to downgrade their state data (you have to pg_dumpall everything and re-import, if you don't have enough working memory to do it, good luck) | 19:56:34 |
| raitobezarius | The latter is just cheap people have to figure out stuff or block their upgrades | 19:56:44 |
| raitobezarius | Therefore, revert is still out of the question to me, but I am open to be proven wrong | 19:56:59 |
|  bendlas joined the room. | 19:59:00 |
| bendlas | 👋 | 19:59:17 |
| raitobezarius | I have to jump in another meeting right now | 19:59:49 |
| raitobezarius | I will people chime in / discuss on issues here and there | 19:59:56 |
| raitobezarius | I'd like to come to a "pre-decision" on Monday ideally that we will announce in Discourse | 20:00:12 |
| raitobezarius | And then we will enforce it | 20:00:17 |
| bendlas | In reply to @raitobezarius:matrix.org
We would break anyone PGSQL 15 deployment That would be unfortunate for sure. But the way the problem seems to present itself, it's a judgement call between breaking unstable users (with the option of re-upgrading the default or downgrading the folder) or breaking stable out-of-tree users (with no option of downgrading). | 20:10:20 |
| raitobezarius | Well stable out of tree users have a downgrading option | 20:11:05 |
| raitobezarius | They stay on 23.05 and figure out what they want to do | 20:11:10 |
| raitobezarius | Plus they have a proper warning | 20:11:17 |
| raitobezarius | Whereas unstable users doesn't have any option to downgrade because it will silently break the postgresql.service | 20:11:41 |
| bendlas | downgrading within the release, but point taken | 20:11:51 |
| bendlas | What actually is the behavior of postgres when started on a folder that's "too new"? Maybe this condition could be checked for, if not at build time, .... | 20:14:09 |
 hexa | so, what I read is that downgrades are not supported by postgresql | 20:14:23 |
|  @gary.garyguo.net:lpc.events joined the room. | 20:14:27 |
| hexa | so people who are on 15 now and want back to 14 would need to dump and restore | 20:14:36 |
| @gary.garyguo.net:lpc.events | Apologize for upgrading postgres version... I migrated from 14 to 15 and everything worked fine, didn't know that it'll break new installations | 20:16:00 |
| @gary.garyguo.net:lpc.events | In reply to @raitobezarius:matrix.org
This is orthogonal to the situation How about remove the default if stateVersion is 23.11, but keep it for older ones? | 20:18:42 |
| hexa | My problem with that PR is that it didn't account for the changelog of postgresl 15. This goes well 500 times and then 1 time it will bite you. | 20:19:28 |
