Horton

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

Abhijit Menon-Sen <ams@2ndquadrant.com>

View thread View on postgr.es
From: Abhijit Menon-Sen <ams@2ndQuadrant.com>
To: Stephen Frost <sfrost@snowman.net>
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-19T00:32:10Z
Lists: pgsql-hackers 
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.

(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.)

-- Abhijit

Commits

  1. PANIC on fsync() failure.

  2. Fix and improve pg_atomic_flag fallback implementation.