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 20150526015451.GS32396@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2015-05-25 21:33:03 -0400, Robert Haas wrote:
> On Mon, May 25, 2015 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Perhaps, but if we didn't have permission to write the file, it's hard to
> > argue that it's our responsibility to fsync it.  So this seems like it's
> > adding complexity without really adding any safety.
> 
> I agree.  I think ignoring fsync failures is a very sensible approach.
> If the files are not writable, they're probably not ours.

The reason we started discussing this is because Tom had the - quite
reasonable - concern that this might not solely be a problem of EACCESS,
but that there could be other errors that we need to ignore to not fail
spuriously.  Say a symlink goes to a binary, which is currently being
executed: ETXTBSY. Or the file is in a readonly filesystem: EROFS.  So
we'd need to ignore a lot of errors, possibly ignoring valid ones.

I personally can see why people will put things in PGDATA itself, if you
put unreadable stuff in some subdirectory that you didn't create
yourself, I see much less reason to tolerate that.

Another thing is whether we should handle a recursive symlink in pgdata?
I personally think not, but...

It's also not just as simple as making fsync_fname fail gracefully upon
EACCESS - the opendir() could fail just as well.

Greetings,

Andres Freund



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Следующее
От: Tom Lane
Дата:
Сообщение: Re: brin regression test intermittent failures