From: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
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 00:32:10 |
Message-ID: | 20180519003210.xehe2kfei5nss4mw@toroid.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
(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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-05-19 01:01:21 | Re: Postgres, fsync, and OSs (specifically linux) |
Previous Message | Stephen Frost | 2018-05-19 00:27:57 | Re: Postgres, fsync, and OSs (specifically linux) |