Re: [HACKERS] pg_dump issues

2017-07-26 Thread Дмитрий Воронин
Hello, 25.07.2017, 11:17, "Victor Drobny" : > > Hello, > > Do you expect to have some flag like '--rename=test->test2'? Yes, I do. > Will dump with test replaced by test2(of course only in related places) > be valid dump in this case? Yes, it will. > What is the

Re: [HACKERS] pg_dump issues

2017-07-25 Thread Victor Drobny
We can't create any schema dump with another (user defined) name. E.g. we dump schema test and we want to save it's dump with test2 name in any format. Those refers to databases dump. Hello, Do you expect to have some flag like '--rename=test->test2'? Will dump with test replaced by test2(of

Re: [HACKERS] pg_dump issues

2017-06-05 Thread Craig Ringer
On 6 June 2017 at 11:37, Дмитрий Воронин wrote: > Hello, > > We are working on one project with postgres as engeneer. > > Bellow is list of inconveniences that we are having with postgresql. We > would like to solve them as possible. > > We can't create any schema dump

[HACKERS] pg_dump issues

2017-06-05 Thread Дмитрий Воронин
Hello,We are working on one project with postgres as engeneer.Bellow is list of inconveniences that we are having with postgresql. We would like to solve them as possible.We can't create any schema dump with another (user defined) name. E.g. we dump schema test and we want to save it's dump with

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Florian Pflug
On Oct2, 2011, at 23:15 , Joe Abbate wrote: I'm somewhat surprised there appears to be no ability to lock a database exclusively for something like pg_dump/pg_restore, so you're not surprised by concurrent activity against the catalogs. I'm guessing the assumption is that MVCC will take care

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Robert Haas
On Sat, Oct 1, 2011 at 9:46 PM, Andrew Dunstan and...@dunslane.net wrote: How would that help? This isn't a lock failure. It is, rather, a failure to lock. Currently, LOCK TABLE only works on tables, and pg_dump only applies it to tables. If the offending object had been a table rather than a

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sat, Oct 1, 2011 at 9:46 PM, Andrew Dunstan and...@dunslane.net wrote: How would that help? This isn't a lock failure. It is, rather, a failure to lock. Currently, LOCK TABLE only works on tables, and pg_dump only applies it to tables. If the

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Alvaro Herrera
Excerpts from Tom Lane's message of lun oct 03 01:47:18 -0300 2011: (Without cassert, it looks like LockReassignCurrentOwner is the next biggest time sink; I'm wondering if there's some sort of O(N^2) behavior in there.) That seems fishy. Even if there weren't quadratic behavior, should

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Andrew Dunstan
On 10/03/2011 12:47 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: While investigating a client problem I just observed that pg_dump takes a surprisingly large amount of time to dump a schema with a large number of views. The client's hardware is quite spiffy, and yet pg_dump

Re: [HACKERS] pg_dump issues

2011-10-03 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of lun oct 03 01:47:18 -0300 2011: (Without cassert, it looks like LockReassignCurrentOwner is the next biggest time sink; I'm wondering if there's some sort of O(N^2) behavior in there.) That seems fishy.

Re: [HACKERS] pg_dump issues

2011-10-02 Thread Joe Abbate
Hi Andrew, On 10/01/2011 09:46 PM, Andrew Dunstan wrote: On 10/01/2011 05:48 PM, Joe Abbate wrote: On 10/01/2011 05:08 PM, Andrew Dunstan wrote: There is also this gem of behaviour, which is where I started: p1p2 begin; drop view foo;

Re: [HACKERS] pg_dump issues

2011-10-02 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: While investigating a client problem I just observed that pg_dump takes a surprisingly large amount of time to dump a schema with a large number of views. The client's hardware is quite spiffy, and yet pg_dump is taking many minutes to dump a

[HACKERS] pg_dump issues

2011-10-01 Thread Andrew Dunstan
While investigating a client problem I just observed that pg_dump takes a surprisingly large amount of time to dump a schema with a large number of views. The client's hardware is quite spiffy, and yet pg_dump is taking many minutes to dump a schema with some 35,000 views. Here's a simple test

Re: [HACKERS] pg_dump issues

2011-10-01 Thread Joe Abbate
On 10/01/2011 05:08 PM, Andrew Dunstan wrote: While investigating a client problem I just observed that pg_dump takes a surprisingly large amount of time to dump a schema with a large number of views. The client's hardware is quite spiffy, and yet pg_dump is taking many minutes to dump a

Re: [HACKERS] pg_dump issues

2011-10-01 Thread Andrew Dunstan
On 10/01/2011 05:48 PM, Joe Abbate wrote: On 10/01/2011 05:08 PM, Andrew Dunstan wrote: While investigating a client problem I just observed that pg_dump takes a surprisingly large amount of time to dump a schema with a large number of views. The client's hardware is quite spiffy, and yet

Re: [HACKERS] - pg_dump issues

2002-09-11 Thread Oliver Elphick
On Wed, 2002-09-11 at 21:19, Tom Lane wrote: In the meantime, I think that we shouldn't mess with pg_dump's basically OID-order-driven dump ordering. It works in normal cases, and adding arbitrary rules to it to fix one corner case is likely to accomplish little except breaking other corner

Re: [HACKERS] - pg_dump issues

2002-09-11 Thread Lamar Owen
On Wednesday 11 September 2002 05:40 pm, Oliver Elphick wrote: On Wed, 2002-09-11 at 21:19, Tom Lane wrote: In the meantime, I think that we shouldn't mess with pg_dump's basically OID-order-driven dump ordering. It works in normal cases, and adding arbitrary rules to it to fix one corner

Re: [HACKERS] - pg_dump issues

2002-09-11 Thread Lamar Owen
On Wednesday 11 September 2002 09:44 pm, Bruce Momjian wrote: Lamar Owen wrote: Bruce, I mentioned a sed/perl/awk script already to massage the dump into a 7.3-friendly form -- but we need to gather the cases that are involved. Methinks every single OpenACS installation will hit this

[HACKERS] pg_dump issues

2001-01-25 Thread Rod Taylor
Could we add a flag to remove the postgres specific information from a pg_dump? -- UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" ~* 'market_type'; BEGIN TRANSACTION; CREATE TEMP TABLE "tr" ("tmp_relname" name, "tmp_reltriggers" smallint); INSERT INTO "tr" SELECT C."relname",

Re: [HACKERS] pg_dump issues

2001-01-25 Thread Philip Warner
At 14:48 24/01/01 -0500, Rod Taylor wrote: Could we add a flag to remove the postgres specific information from a pg_dump? It's easy enough to do, but removing all PG-specific information is probably undesirable since, eg, pg_dump does not dump foreign key constraints in a standard way (it just