Re: fsync-pgdata-on-recovery tries to write to more files than previously

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> Well, that opens us to errors of omission, ie failing to fsync things we
>> should have. Maybe that's an okay risk, but personally I'd judge that
>> "fsync everything and ignore (some?) errors" is probably a more robust
>> approach over time.

> How is it possible to make errors of omission? The list of directories
> in initdb is the complete set of directories that are created for a
> newly-initdb'd database, no? Surely there can't be a database that
> contains vital directories that are not created there? See "subdirs"
> static in initdb.c.

Easy: all you need is to suppose that some of the plain files at top level
of $PGDATA ought to be fsync'd. (I'm fairly sure for example that we took
steps awhile back to force postmaster.pid to be fsync'd.) If there is a
distinction between the fsync requirements of top-level files and
everything else, it is completely accidental and not to be relied on.

And from the other direction, where exactly is it written that
distros/users will only create problematic files at the top level of
$PGDATA? I'd have zero confidence in such an assertion applied to
tablespace directories, for sure.

regards, tom lane