On 10 April 2018 at 13:04, Michael Paquier <mich...@paquier.xyz> wrote: > On Mon, Apr 09, 2018 at 03:02:11PM -0400, Robert Haas wrote: >> Another consequence of this behavior that initdb -S is never reliable, >> so pg_rewind's use of it doesn't actually fix the problem it was >> intended to solve. It also means that initdb itself isn't crash-safe, >> since the data file changes are made by the backend but initdb itself >> is doing the fsyncs, and initdb has no way of knowing what files the >> backend is going to create and therefore can't -- even theoretically >> -- open them first. > > 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. 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. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
