Re: Postgres, fsync, and OSs (specifically linux)
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Abhijit Menon-Sen <ams@2ndquadrant.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-21T04:48:46Z
Lists: pgsql-hackers
On Sat, May 19, 2018 at 6:31 AM, Stephen Frost <sfrost@snowman.net> wrote: > 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. It's not just grep, but tools like cscope, tag. Although, I agree, that adding a function, if all necessary, is more important than convenience of finding all the instances of a certain token easily. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Commits
-
PANIC on fsync() failure.
- 9ccdd7f66e33 12.0 landed
- f1ff5f51d249 9.4.21 landed
- 312435232217 9.5.16 landed
- b9cce9ddfa17 9.6.12 landed
- afbe03f65470 10.7 landed
- 6534d544cd77 11.2 landed
-
Fix and improve pg_atomic_flag fallback implementation.
- 8c3debbbf618 11.0 cited