Skip site navigation (1) Skip section navigation (2)

Re: VACUUMs take twice as long across all nodes

From: Andreas Kostyrka <andreas(at)kostyrka(dot)org>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: VACUUMs take twice as long across all nodes
Date: 2006-10-29 16:24:33
Message-ID: 1162139073.7606.1.camel@andi-lap (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Am Sonntag, den 29.10.2006, 10:34 -0500 schrieb Andrew Sullivan:
> On Sun, Oct 29, 2006 at 03:08:26PM +0000, Gavin Hamill wrote:
> > 
> > This is interesting, but I don't understand.. We've done a full restore
> > from one of these pg_dump backups before now and it worked just great.
> > 
> > Sure I had to DROP SCHEMA _replication CASCADE to clear out all the
> > slony-specific triggers etc., but the new-master ran fine, as did
> > firing up new replication to the other nodes :)
> > 
> > Was I just lucky?
> Yes.  Slony alters data in the system catalog for a number of
> database objects on the replicas.  It does this in order to prevent,
> for example, triggers from firing both on the origin and the replica. 
> (That is the one that usually bites people hardest, but IIRC it's not
> the only such hack in there.)  This was a bit of a dirty hack that
> was supposed to be cleaned up, but that hasn't been yet.  In general,
> you can't rely on a pg_dump of a replica giving you a dump that, when
> restored, actually works.

Actually, you need to get the schema from the master node, and can take
the data from a slave. In mixing dumps like that, you must realize that
there are two seperate parts in the schema dump: "table definitions" and
"constraints". Do get a restorable backup you need to put the table
definitions stuff before your data, and the constraints after the data


> A

In response to


pgsql-performance by date

Next:From: Andrew SullivanDate: 2006-10-29 16:43:19
Subject: Re: VACUUMs take twice as long across all nodes
Previous:From: Andrew SullivanDate: 2006-10-29 15:34:04
Subject: Re: VACUUMs take twice as long across all nodes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group