Jan Nieuwenhuizen writes: > Roel Janssen writes: > >> So, it would be something like: >> postgres pg_upgrade \ >> ... > > It's great to have a recipe `that works', so thanks! > > However, whether or not we automate this, I cannot help to wonder if > we should support downgrading -- at least to the previous version > in this case? > > If I'm not mistaken, everything else in GuixSD will run if I select a > previous system generation in Grub...except for this? > > Is involving postgres developers an option, I'm sure a least one of > the postgresql hackers[cc] are already looking at Guix[SD]? > > Greetings, > janneke
There's a big difference in upgrading and downgrading between guix revisions and doing so in highly stateful databases, unfortunately. I can't speak for postgres specifically, but here's my experience with migrations as the tech lead of MediaGoblin: - upgrades should be taken with extreme caution, and you should back up first. - downgrades should be taken with ten times the amount of caution of upgrades, a vat of coffee to work through the problems, and a barrel of whiskey for when it doesn't. I say that as someone who's mostly given up coffee and doesn't drink alcohol. State changes are bad enough when unidirectional. Django, for instance, provides an API that does both upgrades and downgrades. Almost everybody spends a bunch of time carefully crafting their upgrades, and just leaves their downgrades as the stubs that come with it. These are stubs that drop columns entirely, possibly columns that data was moved to in the migration. Reverse course, and suddenly you don't have a lot of data you used to. What we really want to do is provide the option to snapshot things *before* you do an upgrade, IMO... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
