Re: Postgres, fsync, and OSs (specifically linux)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@anarazel.de>
Cc: Craig Ringer <craig@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-27T23:04:47Z
Lists: 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 +
Commits
-
PANIC on fsync() failure.
- 9ccdd7f66e33 12.0 landed
- f1ff5f51d249 9.4.21 landed
- 312435232217 9.5.16 landed
- b9cce9ddfa17 9.6.12 landed
- afbe03f65470 10.7 landed
- 6534d544cd77 11.2 landed
-
Fix and improve pg_atomic_flag fallback implementation.
- 8c3debbbf618 11.0 cited