Re: [HACKERS] pg_dumpall reccomendation in release notes

On Thu, Aug 21, 2014 at 12:18:46PM -0400, Bruce Momjian wrote: > I have developed the attached patch to address the issues raised above: > > o non-text output of pg_dump is mentioned > o mentions of using OID for keys is removed > o the necessity of pg_dumpall --globals-only is mentioned > o u

Re: [HACKERS] pg_dumpall reccomendation in release notes

On Tue, Feb 25, 2014 at 05:05:09PM -0800, Josh Berkus wrote: > On 02/25/2014 04:42 PM, Bruce Momjian wrote: > > On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote: > >> I'm not sure what "many limitations" you think pg_dumpall has that pg_dump > >> doesn't. > >> > >> I do think that it might

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 04:42 PM, Bruce Momjian wrote: > On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote: >> 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 th

Re: [HACKERS] pg_dumpall reccomendation in release notes

On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote: > 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 >

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 03:59 PM, Tom Lane wrote: > If we had a page discussing the pros and cons of different upgrade > methods, yeah, I'd be in favor of reducing the release-note text to a > pointer to that page. I don't see such a page in a quick skim of the > fine manual's table of contents though? I o

Re: [HACKERS] pg_dumpall reccomendation in release notes

Josh Berkus writes: > On 02/25/2014 03:41 PM, Tom Lane wrote: >> 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

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 03:41 PM, Tom Lane wrote: > Josh Berkus writes: >> Can we change this text in the template release notes? > >> A dump/restore using >> pg_dumpall, >> or use of >> pg_upgrade

Re: [HACKERS] pg_dumpall reccomendation in release notes

Josh Berkus writes: > Can we change this text in the template release notes? > A dump/restore using > pg_dumpall, > or use of > pg_upgrade, is > required for those wishing to m

[HACKERS] pg_dumpall reccomendation in release notes

Bruce, Tom: Can we change this text in the template release notes? A dump/restore using pg_dumpall, or use of pg_upgrade, is required for those wishing to migrate data from an

Re: [HACKERS] pg_dumpall and temp_tablespaces dependency problem

Heikki Linnakangas writes: > Barring objections, I'll write a patch to relax the checking on > default_text_search_config and temp_tablespaces to match search_path. This seems like something that's going to come back again and again. What do you think of changing things so that ALTER ROLE/DATABA

[HACKERS] pg_dumpall and temp_tablespaces dependency problem

create user foouser; create tablespace temptblspc location '/tmp/tmptblspc'; alter user foouser set temp_tablespaces='temptblspc'; Run pg_dumpall. It will produce a dump like: ... CREATE ROLE foouser; ALTER ROLE foouser WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION; ALTE

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Florian Pflug wrote: > On Oct27, 2011, at 23:02 , Bruce Momjian wrote: > > Florian Pflug wrote: > >> On Oct21, 2011, at 16:42 , Phil Sorber wrote: > >>> If you did want to make them immutable, I also like Florian's idea of > >>> a dependency graph. This would make the dumps less readable though. >

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Oct27, 2011, at 23:02 , Bruce Momjian wrote: > Florian Pflug wrote: >> On Oct21, 2011, at 16:42 , Phil Sorber wrote: >>> If you did want to make them immutable, I also like Florian's idea of >>> a dependency graph. This would make the dumps less readable though. >> >> Hm, I kinda reversed my op

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Florian Pflug wrote: > On Oct21, 2011, at 16:42 , Phil Sorber wrote: > > If you did want to make them immutable, I also like Florian's idea of > > a dependency graph. This would make the dumps less readable though. > > Hm, I kinda reversed my opinion on that, though - i.e., I no longer think > tha

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Oct21, 2011, at 16:42 , Phil Sorber wrote: > If you did want to make them immutable, I also like Florian's idea of > a dependency graph. This would make the dumps less readable though. Hm, I kinda reversed my opinion on that, though - i.e., I no longer think that the dependency graph idea has m

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug wrote: > On Oct20, 2011, at 01:19 , Tom Lane wrote: >> Florian Pflug writes: >>> Taking this even further, why do we bother with non-immutable (i.e., >>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET >>> at all? >> >> Y

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Oct20, 2011, at 01:19 , Tom Lane wrote: > Florian Pflug writes: >> Taking this even further, why do we bother with non-immutable (i.e., >> depending on the database's contents) checks during ALTER ROLE/DATABASET SET >> at all? > > Yeah, I was wondering about that one too. It would not solve a

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Florian Pflug writes: > Taking this even further, why do we bother with non-immutable (i.e., > depending on the database's contents) checks during ALTER ROLE/DATABASET SET > at all? Yeah, I was wondering about that one too. It would not solve all the problems here, but skipping validity checks w

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Oct20, 2011, at 00:09 , Tom Lane wrote: > Robert Haas writes: >> On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote: >>> I'm beginning to think that the correct solution to these problems is to >>> greatly restrict what you can set in ALTER ROLE/DATABASE SET. Or at >>> least to document that if

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Robert Haas writes: > On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote: >> I'm beginning to think that the correct solution to these problems is to >> greatly restrict what you can set in ALTER ROLE/DATABASE SET.  Or at >> least to document that if you use it, you get to keep both pieces after >>

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote: > "David E. Wheeler" writes: >> We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with >> lines like these: > >>     ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN >> PASSWORD 'md5bdd7f8e73a214981b1519

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

On Oct 19, 2011, at 2:13 PM, Tom Lane wrote: >>ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN >> PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity'; >>ALTER ROLE dude SET default_tablespace TO 'users'; > > I'm beginning to think that the correct

Re: [HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

"David E. Wheeler" writes: > We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with > lines like these: > ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN > PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity'; > ALTER ROLE dud

[HACKERS] pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Hackers, We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with lines like these: ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity'; ALTER ROLE dude SET default_tablespace TO

Re: [HACKERS] pg_dumpall

Aaron, > I have been having problems using the pg_dumpall function. I am trying to > dump all the information on my database onto a file or view it. Actually > what am trying to achieve is by using the pg_dumpall i can view dead rows > once the db has been dumped into a file. I had a look online a

[HACKERS] pg_dumpall

Hi there, I have been having problems using the pg_dumpall function. I am trying to dump all the information on my database onto a file or view it. Actually what am trying to achieve is by using the pg_dumpall i can view dead rows once the db has been dumped into a file. I had a look online and tr

Re: [HACKERS] pg_dumpall --clean is completely broken

Bruce Momjian writes: > Does your recently-applied patch address any of these TODO items? > Stop dumping CASCADE on DROP TYPE commands in clean mode That has nothing to do with pg_dumpall. > Allow pg_dump --clean to drop roles that own objects or > have privileges Hm

Re: [HACKERS] pg_dumpall --clean is completely broken

Tom Lane wrote: > A thread over in -admin has made me realize the truth of $SUBJECT. > With --clean, pg_dumpall does indeed emit a DROP command for each > role, tablespace, or database ... just before recreating it. This > takes no account of dependencies and so the role and tablespace > drops are

[HACKERS] pg_dumpall --clean is completely broken

A thread over in -admin has made me realize the truth of $SUBJECT. With --clean, pg_dumpall does indeed emit a DROP command for each role, tablespace, or database ... just before recreating it. This takes no account of dependencies and so the role and tablespace drops are pretty much guaranteed to

Re: [HACKERS] pg_dumpall --clean versus roles and shared dependencies

Some time ago I wrote: > I've been trying to figure out what to do about pg_dumpall's --clean > option in view of our recent changes. (for the rest, see http://archives.postgresql.org/pgsql-hackers/2005-07/msg01143.php Since we haven't come up with any bright ideas, and it seems far too late in t

[HACKERS] pg_dumpall --clean versus roles and shared dependencies

I've been trying to figure out what to do about pg_dumpall's --clean option in view of our recent changes. The problem is that pg_dumpall tries to delete existing users and groups by putting this in its output script: DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM p

[HACKERS] pg_dumpall

Hi, In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is this: ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] pg_dumpall problem in 7.1 and cvs

"Oliver Elphick" <[EMAIL PROTECTED]> writes: > If there is a comment on a view, pg_dumpall can put them in the wrong order: I've committed a fix for this in both CVS tip and REL7_1_STABLE. regards, tom lane ---(end of broadcast)---

[HACKERS] pg_dumpall problem in 7.1 and cvs

If there is a comment on a view, pg_dumpall can put them in the wrong order: -- -- pg_dumpall (7.2devel) -- ... -- -- TOC Entry ID 363 (OID 31291) -- -- Name: VIEW "all_persons" Type: COMMENT Owner: -- COMMENT ON VIEW "all_persons" IS 'All persons - individuals or not'; -- -- TOC Entry ID 362 (

Re: [HACKERS] pg_dumpall problem in 7.1 and cvs

"Oliver Elphick" <[EMAIL PROTECTED]> writes: > If there is a comment on a view, pg_dumpall can put them in the wrong order: Drat. I fixed the identical problem for permissions a little while ago, but didn't realize that it extended to comments too. Thanks for the report!

Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)

* Tom Lane <[EMAIL PROTECTED]> [010101 13:16]: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > I noticed today that pg_dumpall from current CVS does *NOT* > > dump a password assiged to the postgres user. > > > I consider this BAD, since if one has to restore from > > a pg_dumpall, one may for

Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)

Larry Rosenman <[EMAIL PROTECTED]> writes: > I noticed today that pg_dumpall from current CVS does *NOT* > dump a password assiged to the postgres user. > I consider this BAD, since if one has to restore from > a pg_dumpall, one may forget to reset the password. I'm unconvinced. The pg_dumpa

Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)

* Larry Rosenman <[EMAIL PROTECTED]> [001231 17:59]: > I noticed today that pg_dumpall from current CVS does *NOT* > dump a password assiged to the postgres user. > > I consider this BAD, since if one has to restore from > a pg_dumpall, one may forget to reset the password. > > LER And, it wa

[HACKERS] pg_dumpall (7.1beta1, current CVS)

I noticed today that pg_dumpall from current CVS does *NOT* dump a password assiged to the postgres user. I consider this BAD, since if one has to restore from a pg_dumpall, one may forget to reset the password. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1

Re: [HACKERS] pg_dumpall --accounts-only

Peter Eisentraut <[EMAIL PROTECTED]> writes: > To make a long story short, a more correct name for this option would be > "--globals-only". Is it okay to change this? Okay with me... regards, tom lane

[HACKERS] pg_dumpall --accounts-only

I've been sneaking a peek at the Great Bridge documentation regarding the pg_dumpaccounts utility. You may recall that I added the pg_dumpall --accounts-only option to provide the same functionality. But it occurred to me that the name is wrong. The way it reads in the GB docs is that pg_dumpac