Re: Postgres, fsync, and OSs (specifically linux) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Postgres, fsync, and OSs (specifically linux)
Date
Msg-id 20180427230447.GA32605@momjian.us
Whole thread Raw
In response to Postgres, fsync, and OSs (specifically linux)  (Andres Freund <andres@anarazel.de>)
Responses Re: Postgres, fsync, and OSs (specifically linux)  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Postgres, fsync, and OSs (specifically linux)
Next
From: Andres Freund
Date:
Subject: Re: Postgres, fsync, and OSs (specifically linux)