1 |
On 02/13/2016 12:43 PM, Mick wrote: |
2 |
> |
3 |
> Thank you Michael. It was pretty painless TBH, almost as easy as upgrading |
4 |
> mysql. ;-) Your page also nicely details the alternative, which I did not |
5 |
> try out. |
6 |
> |
7 |
|
8 |
I wrote that when postgresql-9.0 was released and was the first version |
9 |
that had pg_upgrade. It sounds great at first... I guess it feels |
10 |
dangerous to dump/restore your entire database cluster to a text file |
11 |
(even though I've never had a problem doing it). |
12 |
|
13 |
But, I kept running into problems, even following my own instructions |
14 |
step-by-step. For example, pg_upgrade will refuse to upgrade clusters |
15 |
with different encodings. A dump/restore works just fine there. Plus, it |
16 |
became annoying to have to follow a list every time I needed to do an |
17 |
upgrade (I have more than one postgres server). The pg_upgrade route is |
18 |
extremely sensitive to the order in which you do things. Meanwhile, the |
19 |
dump/restore route I know off the top of my head: |
20 |
|
21 |
1. make sure the new version works |
22 |
2. dump everything |
23 |
3. switch to the new version |
24 |
4. load the dump |
25 |
|
26 |
There are details at each step, but the order can be fudged and it's |
27 |
easy to fix if you forget something. As long as there are no known |
28 |
problems with the dump/restore method, I don't see any reason to bother |
29 |
with the "new" way. |