| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers) |
| Date: | 2017-09-15 00:41:02 |
| Message-ID: | CAB7nPqS9pL7qwRu8ku8byvYYZOEHHXzUAgSJRbP7AENtHT8E_A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 15, 2017 at 8:23 AM, Andreas Joseph Krogh
<andreas(at)visena(dot)com> wrote:
> I tested upgrading from 9.6 to 10 now, using pg_upgrade, and pg_upgrade
> creates the new data-dir with pg_wal "in it" (just like regular initdb), so
> pg_upgrade seems not to care about where the old version's pg_xlog was. You
> have to move (by symlinking) pg_wal to a separate location manually *after*
> running pg_upgrade on the master.
That's true, this should definitely be mentioned in the documentation.
An improvement could be done as well here for pg_upgrade: when using
--link, the new PGDATA created could consider as well the source
pg_wal and create a link to it, and then clean up its contents. I am
not completely sure if this would be worth doing as people are likely
used to the current flow though. The documentation needs to outline
the matter at least.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2017-09-15 00:43:59 | Re: Process startup infrastructure is a mess |
| Previous Message | Amit Langote | 2017-09-15 00:38:55 | Re: Partition-wise join for join between (declaratively) partitioned tables |