Re: Postgres, fsync, and OSs (specifically linux)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Postgres, fsync, and OSs (specifically linux)
Дата
Msg-id 20180427230447.GA32605@momjian.us
обсуждение исходный текст
Ответ на Postgres, fsync, and OSs (specifically linux)  (Andres Freund <andres@anarazel.de>)
Ответы Re: Postgres, fsync, and OSs (specifically linux)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, Apr 27, 2018 at 03:28:42PM -0700, Andres Freund wrote:
> - We need more aggressive error checking on close(), for ENOSPC and
>   EIO. In both cases afaics we'll have to trigger a crash recovery
>   cycle. It's entirely possible to end up in a loop on NFS etc, but I
>   don't think there's a way around that.

If the no-space or write failures are persistent, as you mentioned
above, what is the point of going into crash recovery --- why not just
shut down?  Also, since we can't guarantee that we can write any
persistent state to storage, we have no way of preventing infinite crash
recovery loops, which, based on inconsistent writes, might make things
worse.  I think a single panic with no restart is the right solution.

An additional features we have talked about is running some kind of
notification shell script to inform administrators, similar to
archive_command.  We need this too when sync replication fails.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Postgres, fsync, and OSs (specifically linux)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Postgres, fsync, and OSs (specifically linux)