Horton

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

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-18T23:21:52Z
Lists: pgsql-hackers 
On Thu, Jul 19, 2018 at 7:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 2. I don't like promote_ioerr_to_panic() very much, partly because the
> same pattern gets repeated over and over, and partly because it would
> be awkwardly-named if we discovered that another 2 or 3 errors needed
> similar handling (or some other variant handling).  I suggest instead
> having a function like report_critical_fsync_failure(char *path) that
> ...

Note that if we don't cover *all* errno values, or ...

> 8. Andres suggested to me off-list that we should have a GUC to
> disable the promote-to-panic behavior in case it turns out to be a
> show-stopper for some user.

... we let the user turn this off, then we also have to fix this:

https://www.postgresql.org/message-id/flat/87y3i1ia4w.fsf@news-spur.riddles.org.uk

-- 
Thomas Munro
http://www.enterprisedb.com

Commits

  1. PANIC on fsync() failure.

  2. Fix and improve pg_atomic_flag fallback implementation.