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

Andres Freund <andres(at)anarazel(dot)de> writes:
> On May 24, 2015 7:52:53 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Christoph Berg <myon(at)debian(dot)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 like the rmgr list.

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

regards, tom lane