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)
|
Список | 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 по дате отправления: