On Fri, May 26, 2006 at 12:15:34AM +0200, Andreas Pflug wrote:
> Jim Nasby wrote:
> >Another consideration is that you can use rsync to update a
> >filesystem-level backup, but there's no pg_dump equivalent. On a large
> >database that can make a sizable difference in the amount of time
> >required for a backup.
> That's fine to cut the backup execution time, but to guarantee
> consistency while the cluster is running pg_start_backup/pg_stop_backup
> and WAL archiving will still be necessary.
Of course, but the point is that it would only be necessary while you're
running rsync. If you don't care about being able to actually roll
forward from that backup, you don't need any WAL files from after rsync
completes.
One possible way to accomplish this would be to allow specifying an
archiver command to pg_start_backup, which would then fire up an
archiver for the duration of your backup. Then you can:
SELECT pg_start_backup('label', 'cp -i %p /mnt/server/archivedir/%f
</dev/null');
rsync
SELECT pg_stop_backup();
No messing with postgresql.conf, no need to HUP the postmaster.
Perhaps the OP would be interested in coding this up, or sponsoring
someone to do so, since I think it provide what they were looking for.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
