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 using
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 be time to
Bruce, Tom:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
pg_upgradehttp://www.postgresql.org/docs/9.3/static/pgupgrade.html, is
required for those wishing to migrate data from any
Josh Berkus j...@agliodbs.com writes:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
pg_upgradehttp://www.postgresql.org/docs/9.3/static/pgupgrade.html, is
required for those
On 02/25/2014 03:41 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Can we change this text in the template release notes?
A dump/restore using
pg_dumpallhttp://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html,
or use of
Josh Berkus j...@agliodbs.com 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
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 owe
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
could
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 that the
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;
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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.
Hm, I
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
that the
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 opinion on
On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug f...@phlo.org wrote:
On Oct20, 2011, at 01:19 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
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
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
David E. Wheeler da...@kineticode.com 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';
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
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us 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
On Oct20, 2011, at 00:09 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
On Oct20, 2011, at 01:19 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
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
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 and
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
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
Bruce Momjian br...@momjian.us 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
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
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
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
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
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 (OID
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_dumpall
* 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 forget to reset
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
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
38 matches
Mail list logo
