Horton

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

Craig Ringer <craig@2ndquadrant.com>

View thread View on postgr.es
From: Craig Ringer <craig@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Asim R P <apraveen@pivotal.io>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>
Date: 2018-10-19T05:41:55Z
Lists: pgsql-hackers 
On Fri, 19 Oct 2018 at 07:27, Thomas Munro <thomas.munro@enterprisedb.com>
wrote:

>
> 2.  I am +1 on back-patching Craig's PANIC-on-failure logic.  Doing
> nothing is not an option I like.  I have some feedback and changes to
> propose though; see attached.
>

Thanks very much for the work on reviewing and revising this.


> I don't see why sync_file_range(SYNC_FILE_RANGE_WRITE) should get a
> pass here.  Inspection of some version of the kernel might tell us it
> can't advance the error counter and report failure, but what do we
> gain by relying on that?  Changed.
>

I was sure it made sense at the time, but I can't explain that decision
now, and it looks like we should treat it as a failure.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. PANIC on fsync() failure.

  2. Fix and improve pg_atomic_flag fallback implementation.