Re: fsync error handling in pg_receivewal, pg_recvlogical

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: fsync error handling in pg_receivewal, pg_recvlogical
Дата
Msg-id 20190329130505.GG1954@paquier.xyz
обсуждение исходный текст
Ответ на fsync error handling in pg_receivewal, pg_recvlogical  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: fsync error handling in pg_receivewal, pg_recvlogical
Список pgsql-hackers
On Fri, Mar 29, 2019 at 12:48:09PM +0100, Peter Eisentraut wrote:
> Do we need to review the fsync error handling in pg_receivewal and
> pg_recvlogical, following the recent backend changes?  The current
> default behavior is that these tools will log fsync errors and then
> reconnect and proceed with the next data streaming in.  As a result, you
> might then have some files in the accumulated WAL that have not been
> fsynced.  Perhaps a hard exit would be more appropriate?

Yes, I think that we are going to need an equivalent of that for all
frontend tools.  At various degrees, making sure that a fsync happens
is also important for pg_dump, pg_basebackup, pg_rewind and
pg_checksums so it is not only a problem of the two tools you mention.
It seems to me that the most correct way to have those failures would
be to use directly exit(EXIT_FAILURE) in file_utils.c where
appropriate.
--
Michael

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Add exclusive backup deprecation notes to documentation
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru