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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: fsync-pgdata-on-recovery tries to write to more files than previously
Дата
Msg-id 20150529174232.GB24118@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2015-05-29 13:14:18 -0400, Tom Lane wrote:
> Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> As I mentioned yesterday, I'm not really on board with ignoring EACCES,
> except for the directories-on-Windows case.  Since we're only logging
> the failures anyway, I think it is reasonable to log a complaint for any
> unwritable file in the data directory.

That sounds like a potentially nontrivial amount of repetitive log bleat
after every crash start? One which the user can't really stop?

> Also I want to get rid of the ETXTBSY special cases.  That one doesn't
> seem like something that we should silently ignore: what the heck are
> executables doing in the data directory?  Or is there some other meaning
> on Windows?

I've seen a bunch of binaries placed in the data directory as
archive/restore commands. Those will be busy a good amount of the
time. While it'd not be my choice to do that, it's not entirely
unreasonable.

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Need Force flag for pg_drop_replication_slot()