Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Tom Lane |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | 26511.1432479173@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Christoph Berg <myon@debian.org>) |
Ответы |
Re: fsync-pgdata-on-recovery tries to write to more files than previously
|
Список | pgsql-hackers |
Christoph Berg <myon@debian.org> writes: > Re: To Andres Freund 2015-05-24 <20150524075244.GB27048@msg.df7cb.de> >> Re: Andres Freund 2015-05-24 <20150524005245.GD32396@alap3.anarazel.de> >>> How about, to avoid masking actual problems, we have a more >>> differentiated logic for the toplevel data directory? > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: