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
timesthe amount of caution of upgrades, a vat of coffee to work through the problems, and a barrel of whiskey for
whenit 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...
