Re: Proposed patch: Smooth replication during VACUUM FULL

From: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed patch: Smooth replication during VACUUM FULL
Date: 2011-05-01 00:37:10
Message-ID: BANLkTikMAx4G0uBLJ10kzUXFpKSWbZVCxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 30, 2011 at 5:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <jaime(at)2ndquadrant(dot)com> writes:
>> On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
>>> I have noticed that during VACUUM FULL on reasonably big tables, replication
>>> lag climbs. In order to smooth down the replication lag, I propose the
>>> attached patch which enables vacuum delay for VACUUM FULL.
>
>> AFAICS, the problem is that those operations involve the rebuild of
>> tables, so we can't simply stop in the middle and wait because we will
>> need to hold a strong lock more time... also the patch seems to be
>> only doing something for CLUSTER and not for VACUUM FULL.
>> or am i missing something?
>
[...]
> The argument about holding locks longer doesn't seem relevant to me:
> enabling delays during VACUUM FULL would've had that effect in the old
> implementation, too, but nobody ever complained about that,

you mean, no complaints except the usual: "don't use VACUUM FULL"?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2011-05-01 02:17:04 a bit more precise MaxOffsetNumber
Previous Message Mark Kirkwood 2011-05-01 00:10:31 Re: increasing collapse_limits?