On May 24, 2015 7:52:53 AM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >Christoph Berg <m...@debian.org> writes: >> Re: To Andres Freund 2015-05-24 <20150524075244.gb27...@msg.df7cb.de> >>> Re: Andres Freund 2015-05-24 ><20150524005245.gd32...@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.
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. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
