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 possible scenario for the ren
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 co
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 with another (user defined)
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 te
Alvaro Herrera 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. Even if there weren't
On 10/03/2011 12:47 AM, Tom Lane wrote:
Andrew Dunstan 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 minut
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 t
Robert Haas writes:
> On Sat, Oct 1, 2011 at 9:46 PM, Andrew Dunstan 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 rat
On Sat, Oct 1, 2011 at 9:46 PM, Andrew Dunstan 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 view, pg_dump would
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
Andrew Dunstan 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 schema with some 35,0
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;
>>>
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 pg_d
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 sc
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 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
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 issue.
>
> How big is the problem? It's looking bigger with each
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
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 corn
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
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", count(T.
21 matches
Mail list logo
