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