Magnus Hagander <mag...@hagander.net> wrote: > We'd need a second script/command to call to figure out where to > restart from in that case, no? I see your point; I guess we would need that. > It should be safe to just rsync the archive directory as it's > being written by pg_streamrecv. Doesn't that give you the property > you're looking for - local machine gets data streamed in live, > remote machine gets it rsynced every minute? Well the local target is a can't run pg_streamrecv -- it's a backup machine where we pretty much have rsync and nothing else. We could run pg_streamrecv on the database server itself and rsync to the local machine every minute. I just checked with the DBA who monitors space issues for such things, and it would be OK to rsync the uncompressed file to the local backup as it is written (we have enough space for it without compression) as long as we compress it before sending it to the central location. For that, your idea to fire a script on completion of the file would work -- we could maintain both raw and compressed files on the database server for rsync to the two locations. You can probably see the appeal of filtering it as it is written, though, if that is feasible. :-) -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
