Re: client-side fsync() error handling

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: client-side fsync() error handling
Дата
Msg-id 20200212052819.GD1464@paquier.xyz
обсуждение исходный текст
Ответ на client-side fsync() error handling  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: client-side fsync() error handling  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Feb 11, 2020 at 09:22:54AM +0100, Peter Eisentraut wrote:
> Digging around through the call stack, I think changing fsync_fname() to
> just call exit(1) on errors instead of proceeding would address most of
> that.
>
> Thoughts?

Doing things as you do in your patch sounds fine to me for this part.
Now, don't we need to care about durable_rename() and make the
panic-like failure an optional choice?  From what I can see, this
routine is used now in the backend for pg_basebackup to rename
temporary history files or partial WAL segments.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pgsql: walreceiver uses a temporary replication slot by default
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Getting rid of some more lseek() calls