Change:
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. I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)

Discussion:
<!-- FIXME: render nicely --> <!-- FIXME: source can be added automatically --> <para> <del> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </del> <ins> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </ins> </para> <para> <del> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </del> <ins> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </ins> </para> <!-- FIXME: more stuff, like maintainer? --> <para>

<title>Configuring</title> <para> <del> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </del> <ins> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </ins> <programlisting> <xref linkend="opt-services.postgresql.enable"/> = true; <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; </programlisting> <del> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </del> <ins> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </ins> </para> <!--

--> <para> <del> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </del> <ins> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </ins> <programlisting> <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql"; </programlisting>

<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;'

... </screen> </para> <para> <del> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </del> <ins> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </ins> <programlisting> <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; <xref linkend="opt-services.postgresql.extraPlugins"/> = with pkgs.postgresql_11.pkgs; [

]; </programlisting> </para> <para> <del> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </del> <ins> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </ins> <programlisting> self: super: { postgresql_custom = self.postgresql_11.withPackages (ps: [

} </programlisting> </para> <para> <del> Here's a recipe on how to override a particular plugin through an overlay: </del> <ins> Here's a recipe on how to override a particular plugin through an overlay: </ins> <programlisting> self: super: { postgresql_11 = super.postgresql_11.override { this = self.postgresql_11; } // {