Re: Documentation Update: Document pg_start_backup checkpoint behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Documentation Update: Document pg_start_backup checkpoint behavior
Date: 2009-04-04 14:40:42
Message-ID: 18066.1238856042@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> The solution Heikki is proposing is to let the user choose immediate
>> or slow checkpoint. I agree that there's not much point in the latter
>> if you are using something dumb like tar to take the filesystem backup,
>> but maybe the user has something smarter that won't cause such a big
>> I/O storm.

> If the user is knowledgeable enough to use a smarter backup tool, he's
> probably knowledgeable enough to put pg_start_backup('foo', true)
> instead of just pg_start_backup('foo') in his scripts. But a new user
> who's just playing around and making his first backup, probably using
> tar, isn't.

It's not actually that difficult to have a tar backup be rate-limited.
If you're dumping the tar output onto a tape drive, or sending it across
a network, or indeed doing anything except dropping it onto another
local disk drive, you are going to find that tar is not saturating
your disk.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-04 15:10:07 Re: GetCurrentVirtualXIDs()
Previous Message Greg Stark 2009-04-04 14:12:53 Re: Saner interval hash function