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
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
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
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
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
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
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
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
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
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.
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;
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
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
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
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
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
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
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
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",
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
20 matches
Mail list logo