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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Run pgindent now?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable