On Sun, Mar 16, 2014 at 10:23 AM, MauMau <maumau...@gmail.com> wrote: > The PostgreSQL documentation describes cp (on UNIX/Linux) or copy (on > Windows) as an example for archive_command. However, cp/copy does not sync > the copied data to disk
I'm actually a lot less concerned about fsyncing the backup than I am about fsyncing the restore. The backup is just a bunch of files for the user to make use of. They might copy them around, compress them, move them onto tape or other storage. They need to be aware of the persistence of whatever storage system they're putting them in. But when they do a restore they just untar or whatever other extraction tool and then hand those files to Postgres to maintain. I bet the number of people who fsync or call sync the data files after untarring their backups is vanishingly small and problems could manifest later after Postgres has been running. WAL-e recently changed to fsync each data file and the directories containing them after restore. But perhaps Postgres should open and fsync each file in the database when it starts up? In most file systems files written to are guaranteed to be synced within a configurable amount of time (in some systems unless the filesystem can't keep up). So the practical risk may be small. But in theory a database that wasn't synced when it was restored could suddenly lose files days or months later when a crash occurs and some data files weren't touched by the database in the intervening time. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers