Horton

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

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Craig Ringer <craig@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-19T01:01:21Z
Lists: pgsql-hackers 
Greetings,

* Abhijit Menon-Sen (ams@2ndQuadrant.com) wrote:
> At 2018-05-18 20:27:57 -0400, sfrost@snowman.net wrote:
> >
> > I don't agree with the general notion that we can't have a function
> > which handles the complicated bits about the kind of error because
> > someone grep'ing the source for PANIC might have to do an additional
> > lookup.
> 
> Or we could just name the function promote_eio_to_PANIC.

Ugh, I'm not thrilled with that either.

> (I understood the objection to be about how 'grep PANIC' wouldn't find
> these lines at all, not that there would be an additional lookup.)

... and my point was that 'grep PANIC' would, almost certainly, find the
function promote_eio_to_panic(), and someone could trivially look up all
the callers of that function then.

Thanks!

Stephen

Commits

  1. PANIC on fsync() failure.

  2. Fix and improve pg_atomic_flag fallback implementation.