On Tue, Apr 10, 2018 at 01:37:19PM +0800, Craig Ringer wrote: > On 10 April 2018 at 13:04, Michael Paquier <mich...@paquier.xyz> wrote: >> And pg_basebackup. And pg_dump. And pg_dumpall. Anything using initdb >> -S or fsync_pgdata would enter in those waters. > > ... but *only if they hit an I/O error* or they're on a FS that > doesn't reserve space and hit ENOSPC.
Sure. > It still does 99% of the job. It still flushes all buffers to > persistent storage and maintains write ordering. It may not detect and > report failures to the user how we'd expect it to, yes, and that's not > great. But it's hardly throw up our hands and give up territory > either. Also, at least for initdb, we can make initdb fsync() its own > files before close(). Annoying but hardly the end of the world. Well, I think that there is place for improving reporting of failure in file_utils.c for frontends, or at worst have an exit() for any kind of critical failures equivalent to a PANIC. -- Michael
signature.asc
Description: PGP signature
