Re: Proposed patch: Smooth replication during VACUUM FULL

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

In response to

Browse pgsql-hackers by date

  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