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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres, fsync, and OSs (specifically linux)
Date: 2018-05-19 01:01:21
Message-ID: 20180519010121.GV27724@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Abhijit Menon-Sen (ams(at)2ndQuadrant(dot)com) wrote:
> At 2018-05-18 20:27:57 -0400, sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-05-19 01:05:41 Re: perl checking
Previous Message Abhijit Menon-Sen 2018-05-19 00:32:10 Re: Postgres, fsync, and OSs (specifically linux)