Re: VACUUMs take twice as long across all nodes - Mailing list pgsql-performance

From Andrew Sullivan
Subject Re: VACUUMs take twice as long across all nodes
Date
Msg-id 20061029145825.GB14585@phlogiston.dyndns.org
Whole thread Raw
In response to Re: VACUUMs take twice as long across all nodes  (Gavin Hamill <gdh@laterooms.com>)
Responses Re: VACUUMs take twice as long across all nodes
List pgsql-performance
Ok, I see Tom has diagnosed your problem.  Here are more hints
anyway:

On Fri, Oct 27, 2006 at 10:20:25AM +0100, Gavin Hamill wrote:
> > table bloat in various slony-related tables.
>
> I know it takes longer, I know it blocks. It's never been a problem

The problem from a VACUUM FULL is that its taking longer causes the
vacuums on (especially) pg_listen and sl_log_[n] to be unable to
recover as many rows (because there's an older transaction around).
This is a significant area of vulnerability in Slony.  You really
have to readjust your vacuum assumptions when using Slony.

> > 3.    Your backups "from the slave" aren't done with pg_dump,
> > right?
>
> Em, they are indeed. I assumed that MVCC would ensure I got a
> consistent snapshot from the instant when pg_dump began. Am I wrong?

That's not the problem.  The problem is that when you restore the
dump of the slave, you'll have garbage.  Slony fools with the
catalogs on the replicas.  This is documented in the Slony docs, but
probably not in sufficiently large-type bold italics in red with the
<blink> tag set as would be appropriate for such a huge gotcha.
Anyway, don't use pg_dump on a replica.  There's a tool that comes
with slony that will allow you to take consistent, restorable dumps
from replicas if you like.  (And you might as well throw away the
dumpfiles from the replicas that you have.  They won't work when you
restore them.)

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
        --H.W. Fowler

pgsql-performance by date:

Previous
From: Andreas Kostyrka
Date:
Subject: partitioned table performance
Next
From: Gavin Hamill
Date:
Subject: Re: VACUUMs take twice as long across all nodes