9.2 upgrade glitch with search_path

Scott Ribe <scott_ribe@elevated-dev.com> writes:

Built & installed 9.2.3. Dumped 9.1 db (using 9.2 pg_dump IIRC). Restored.
Database search path was not restored. Had to execute alter database ... set search_path to...

That's a hole in the particular dump methodology you selected:

pg_dumpall -g -f roles.dump
pg_dump -F c -Z 0 -v pedcard > db.dump

pg_dump does not dump/restore database properties, only database
contents. Properties are the responsibility of pg_dumpall, which
you bypassed (for databases anyway).

There's been some discussion of refactoring these responsibilities,
but no consensus.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Jan 13, 2013, at 2:51 PM, Tom Lane wrote:

That's a hole in the particular dump methodology you selected:

pg_dumpall -g -f roles.dump
pg_dump -F c -Z 0 -v pedcard > db.dump

pg_dump does not dump/restore database properties, only database
contents. Properties are the responsibility of pg_dumpall, which
you bypassed (for databases anyway).

There's been some discussion of refactoring these responsibilities,
but no consensus.

Ah, this is my first upgrade using that methodology, in order to get concurrent restore functionality. Prior to this I've always used pg_dumpall.

--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Sun, Jan 13, 2013 at 04:51:55PM -0500, Tom Lane wrote:

Scott Ribe <scott_ribe@elevated-dev.com> writes:

Built & installed 9.2.3. Dumped 9.1 db (using 9.2 pg_dump IIRC). Restored.
Database search path was not restored. Had to execute alter database ... set search_path to...

That's a hole in the particular dump methodology you selected:

pg_dumpall -g -f roles.dump
pg_dump -F c -Z 0 -v pedcard > db.dump

pg_dump does not dump/restore database properties, only database
contents. Properties are the responsibility of pg_dumpall, which
you bypassed (for databases anyway).

There's been some discussion of refactoring these responsibilities,
but no consensus.

pg_upgrade fixed this for pg_dumpall -g --binary-upgrade by outputing
the per-database settings.

Isn't this a bug? Seems there is no way to get these exported without
pg_dumpall non-'g' mode.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Bruce Momjian <bruce@momjian.us> writes:

On Sun, Jan 13, 2013 at 04:51:55PM -0500, Tom Lane wrote:

pg_dump does not dump/restore database properties, only database
contents. Properties are the responsibility of pg_dumpall, which
you bypassed (for databases anyway).

Isn't this a bug? Seems there is no way to get these exported without
pg_dumpall non-'g' mode.

No, it's not a bug. It is something that'd be nice to make more
flexible, but "bug" is an inappropriate pejorative. (If you are
unsure about the dividing line, ask yourself if we'd back-patch
such a change.)

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general