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 13871.1432921756@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Andres Freund <andres@anarazel.de>)
Ответы Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Andres Freund <andres@anarazel.de>)
Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Christoph Berg <myon@debian.org>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> 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?

Why can't the user stop it?  We won't be bleating about the case of a
symlink to a non-writable file someplace else, which is the Debian use
case.  I don't see a very good excuse to have a non-writable file right
in the data directory.

>> 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.

I'd say it's a pretty damn-fool arrangement: for starters, it's
an unnecessary security hazard.

In any case, if the cost of such a file is one more line of log output
during a crash restart, most people would have no problem at all in
ignoring that log output.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgindent vs emacs
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Need Force flag for pg_drop_replication_slot()