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
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? |