On 02/25/2014 03:41 PM, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> Can we change this text in the template release notes?
>
>> A dump/restore using
>> pg_dumpall<http://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html>,
>> or use of
>> pg_upgrade<http://www.postgresql.org/docs/9.3/static/pgupgrade.html>, is
>> required for those wishing to migrate data from any previous release.
>
>> Again, here we're recommending pg_dumpall with its many limitations, and
>> not mentioning pg_dump/pg_restore at all. This has caused several
>> people to ask me if pg_dump is not supported for upgrading anymore. Fix?
>
> There's a very good reason for not recommending pg_dump in this context:
> it won't dump everything. Yeah, if you know what you're doing, you might
> use per-database pg_dump runs plus pg_dumpall -g to catch the roles etc,
> but we're not going to try to wedge all that info into one or two
> sentences of release-note boilerplate. If you can get that right then
> you don't need the release notes to remind you anyway. If you aren't
> likely to get it right then the release notes would do you no service
> by suggesting it.
Right. But the fact that we don't mention it *at all* has caused some
users to ask me if regular pg_dump doesn't work for upgrades anymore.
Which reminds me, I need to get the doc patch for the upgrade page in
this week.
It does make me wonder if we should direct users to the upgrade page
though, instead of the individual command pages.
> I'm not sure what "many limitations" you think pg_dumpall has that pg_dump
> doesn't.
Lack of parallel dump and restore is the biggest one.
> I do think that it might be time to reword this to recommend pg_upgrade
> first, though. ISTM that the current wording dates from when pg_upgrade
> could charitably be described as experimental.
Yah.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
