Code change:
<title>Upgrading</title> <para> <del> FIXME: document dump/upgrade/load cycle. </del> <ins> Major PostgreSQL upgrade requires PostgreSQL downtime and a few imperative steps to be called. To simplify this process, use the following NixOS module: <programlisting> containers.temp-pg.config.services.postgresql = { enable = true; package = pkgs.postgresql_12; ## set a custom new dataDir # dataDir = "/some/data/dir"; }; environment.systemPackages = let newpg = config.containers.temp-pg.config.services.postgresql; in [ (pkgs.writeScriptBin "upgrade-pg-cluster" '' set -x export OLDDATA="${config.services.postgresql.dataDir}" export NEWDATA="${newpg.dataDir}" export OLDBIN="${config.services.postgresql.package}/bin" export NEWBIN="${newpg.package}/bin" install -d -m 0700 -o postgres -g postgres "$NEWDATA" cd "$NEWDATA" sudo -u postgres $NEWBIN/initdb -D "$NEWDATA" systemctl stop postgresql    # old one sudo -u postgres $NEWBIN/pg_upgrade  --old-datadir "$OLDDATA" --new-datadir "$NEWDATA"  --old-bindir $OLDBIN --new-bindir $NEWBIN  "$@" '') ]; </programlisting> </ins> </para> <ins> <para> The upgrade process is: </para> <orderedlist> <listitem> <para> Rebuild nixos configuration with the configuration above added to your <filename>configuration.nix</filename>. Alternatively, add that into separate file and reference it in <literal>imports</literal> list. </para> </listitem> <listitem> <para> Login as root (<literal>sudo su -</literal>) </para> </listitem> <listitem> <para> Run <literal>upgrade-pg-cluster</literal>. It will stop old postgresql, initialize new one and migrate old one to new one. You may supply arguments like <literal>--jobs 4</literal> and <literal>--link</literal> to speedup migration process. See <link xlink:href="https://www.postgresql.org/docs/current/pgupgrade.html" /> for details. </para> </listitem> <listitem> <para> Change postgresql package in NixOS configuration to the one you were upgrading to, and change <literal>dataDir</literal> to the one you have migrated to. Rebuild NixOS. This should start new postgres using upgraded data directory. </para> </listitem> <listitem> <para> After upgrade you may want to <literal>ANALYZE</literal> new db. </para> </listitem> </orderedlist> </ins> </section> <section xml:id="module-services-postgres-options"> <title>Options</title> <para> <del> A complete list of options for the PostgreSQL module may be found <link linkend="opt-services.postgresql.enable">here</link>. </del> <ins> A complete list of options for the PostgreSQL module may be found <link linkend="opt-services.postgresql.enable">here</link>. </ins> </para> </section> <section xml:id="module-services-postgres-plugins"> <title>Plugins</title> <para> <del> Plugins collection for each PostgreSQL version can be accessed with <literal>.pkgs</literal>. For example, for <literal>pkgs.postgresql_11</literal> package, its plugin collection is accessed by <literal>pkgs.postgresql_11.pkgs</literal>: </del> <ins> Plugins collection for each PostgreSQL version can be accessed with <literal>.pkgs</literal>. For example, for <literal>pkgs.postgresql_11</literal> package, its plugin collection is accessed by <literal>pkgs.postgresql_11.pkgs</literal>: </ins> <screen> <prompt>$ </prompt>nix repl '&lt;nixpkgs&gt;'

Related discussion:
text: to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.