Magnus Hagander <mag...@hagander.net> wrote: >> If you could keep the development "friendly" to such features, I >> may get around to adding them to support our needs.... > > Would it be enough to have kind of an "archive_command" switch > that says "whenever you've finished a complete wal segment, run > this command on it"? That would allow some nice options. I've been thinking what would be the ideal use of this with our backup scheme, and the best I've thought up would be that each WAL segment file would be a single output stream, with the option of calling a executable (which could be a script) with the target file name and then piping the stream to it. At 16MB or a forced xlog switch, it would close the stream and call the executable again with a new file name. You could have a default executable for the default behavior, or just build in a default if no executable is specified. The reason I like this is that I could pipe the stream through pg_clearxlogtail and gzip pretty much "as is" to the locations on the database server currently used for rsync to the two targets, and the rsync commands would send the incremental changes once per minute to both targets. I haven't thought of another solution which provides incremental transmission of the WAL to the local backup location, which would be a nice thing to have, since this is most crucial when the WAN is down and not only is WAL data not coming back to our central location, but our application framework based replication stream isn't making back, either. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
