On Thu, Dec 30, 2010 at 13:30, Aidan Van Dyk <ai...@highrise.ca> wrote: > On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander <mag...@hagander.net> wrote: > >>> As the README says that is not self-contained (for no fault of its own) and >>> one should typically set archive_command to guarantee zero WAL loss. >> >> Yes. Though you can combine it fine with wal_keep_segments if you >> think that's safe - but archive_command is push and this tool is pull, >> so if your backup server goes down for a while, pg_streamrecv will get >> a gap and fail. Whereas if you configure an archive_command, it will >> queue up the log on the master if it stops working, up to the point of >> shutting it down because of out-of-disk. Which you *want*, if you want >> to be really sure about the backups. > > I was thinking I'ld like use pg_streamrecv to "make" my archive, and > the archive script on the master would just "verify" the archive has > that complete segment. > > This get's you an archive synced as it's made (as long as streamrecv > is running), and my "verify"archive command would make sure that if > for some reason, the backup archive went "down", the wal segments > would be blocked on the master until it's up again and current.
That's exactly the method I was envisionning, and in fact that I am using in a couple of cases - jus thaven't documented it properly :) Since pg_streamrecv only moves a segment into the correct archive location when it's completed, the archive_command only needs to check if the file *exists* - if it does, it's transferred, if not, it returns an error to make sure the wal segments don't get cleaned out. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
