Cache flushing isn't an atomic operation though. Even if the ordering is right, you are likely to have a partial fsync on the disk when the lights go out - isn't your FS still corrupt?
On 07 Jul 2015, at 21:53, Heikki Linnakangas <hlinn...@iki.fi> wrote: > On 07/07/2015 09:01 PM, Wes Vaske (wvaske) wrote: > > Right, to be precise, the problem isn't the drive lies about fsync(). It lies > about FLUSH CACHE instead. Search & replace fsync() with FLUSH CACHE, and the > same question remains: When the drive breaks its promise wrt. FLUSH CACHE, > does it nevertheless guarantee that the order the data is eventually flushed > to disk is consistent with the order in which the data and FLUSH CACHE were > sent to the drive? That's an important distinction, because it makes the > difference between "the most recent data the application saved might be lost > even though the FLUSH CACHE command returned" and "your filesystem is > corrupt". > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
