Re: pg_dumpall reccomendation in release notes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dumpall reccomendation in release notes
Date
Msg-id 2983.1393371686@sss.pgh.pa.us
Whole thread Raw
In response to pg_dumpall reccomendation in release notes  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_dumpall reccomendation in release notes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

I'm not sure what "many limitations" you think pg_dumpall has that pg_dump
doesn't.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster
Next
From: Josh Berkus
Date:
Subject: Re: pg_dumpall reccomendation in release notes