## Stephen Frost (sfrost@xxxxxxxxxxx): > Worse, such scripts run the serious risk of losing WAL if a crash > happens because nothing is ensuring that the WAL has been sync'd to disk > before returning from the archive_command. That risk already exists when using rsync/scp/scp/... and should be mitigated by filesystem settings on the receiving side. > Most of the existing tools for dealing with WAL archival (pgbackrest, > barman and WAL-E, at least) already log successful and unsuccessful > archive command runs. I'm pretty sure barman supports back to 8.4 and I > know pgbackrest does. Barman would have to use rsync for the archiving with PostgreSQL 8.4 (pg_receivexlog only came along in 9.2, replication slots in 9.4). Logging will not happen on completion of archive_command (barman doesn't know much about that) but only when the xlog segment is being processed by barman - which could be quite some time later. Regards, Christoph -- Spare Space. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general