From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
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-02 15:12:56 |
Message-ID: | 1304349046-sup-7723@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Bernd Helmle's message of sáb abr 30 19:40:00 -0300 2011:
>
>
> --On 30. April 2011 20:19:36 +0200 Gabriele Bartolini
> <gabriele(dot)bartolini(at)2ndQuadrant(dot)it> wrote:
>
> > 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.
>
> Hmm, but this will move one problem into another. You need to hold exclusive
> locks longer than necessary and given that we discourage the regular use of
> VACUUM FULL i cannot see a real benefit of it...
With the 8.4 code you had the possibility of doing so, if you so wished.
It wasn't enabled by default. (Say you want to vacuum a very large
table that is not critical to operation; so you can lock it for a long
time without trouble, but you can't have this vacuum operation cause
delays in the rest of the system due to excessive I/O.)
The argument seems sane to me. I didn't look into the details of the
patch though.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-05-02 15:15:09 | Re: HTML tags :/ |
Previous Message | Johann 'Myrkraverk' Oskarsson | 2011-05-02 14:41:21 | (Better) support for cross compiled external modules |