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

Andres Freund <andres@anarazel.de> writes:
> On May 24, 2015 7:52:53 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Christoph Berg <myon@debian.org> writes:
>>> pg_log/ is also admin domain. What about only recursing into
>>> well-known directories + postgresql.auto.conf?

>> The idea that this code would know exactly what's what under $PGDATA
>> scares me.  I can positively guarantee that it would diverge from
>> reality over time, and nobody would notice until it ate their data,
>> failed to start, or otherwise behaved undesirably.
>> 
>> pg_log/ is a perfect example, because that is not a hard-wired
>> directory name; somebody could point the syslogger at a different place
>> very easily.  Wiring in special behavior for that name is just wrong.
>> 
>> I would *much* rather have a uniform rule for how to treat each file
>> the scan comes across.  It might take some tweaking to get to one that
>> works well; but once we did, we could have some confidence that it
>> wouldn't break later.

> If we'd merge it with initdb's list I think I'd not be that bad. I'm thinking of some header declaring it, roughly
likethe rmgr list.
 

pg_log/ is a counterexample to that idea too; initdb doesn't know about it
(and shouldn't).
        regards, tom lane