Re: client-side fsync() error handling

Поиск
Список
Период
Сортировка
Искать
От
Peter Eisentraut
Тема
Re: client-side fsync() error handling
Дата
Msg-id
0412a2fb-cbde-08c6-9ff2-cfab5c27a3b8@2ndquadrant.com
Ответ на
Re: client-side fsync() error handling (Michael Paquier)
Список
Дерево обсуждения
client-side fsync() error handling Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: client-side fsync() error handling Michael Paquier <michael@paquier.xyz>
Re: client-side fsync() error handling Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: client-side fsync() error handling Michael Paquier <michael@paquier.xyz>
Re: client-side fsync() error handling Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: client-side fsync() error handling Michael Paquier <michael@paquier.xyz>
Re: client-side fsync() error handling Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: client-side fsync() error handling Michael Paquier <michael@paquier.xyz> 
On 2020-02-12 06:28, Michael Paquier wrote:
> 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.

durable_rename() calls fsync_fname(), so it would be covered by this 
change.  The other file access calls in there can be handled by normal 
error handling, I think.  Is there any specific scenario you have in mind?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления
Предыдущее
От: Peter Eisentraut
Дата:
Следующее
От: Peter Eisentraut
Дата:
FAQ