| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-07-18 23:21:52 |
| Message-ID: | CAEepm=3yQ5OUVJWR5SScuMo36DiPqsEjhqtEkytEZ+=vTyKT1A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 19, 2018 at 7:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 2. I don't like promote_ioerr_to_panic() very much, partly because the
> same pattern gets repeated over and over, and partly because it would
> be awkwardly-named if we discovered that another 2 or 3 errors needed
> similar handling (or some other variant handling). I suggest instead
> having a function like report_critical_fsync_failure(char *path) that
> ...
Note that if we don't cover *all* errno values, or ...
> 8. Andres suggested to me off-list that we should have a GUC to
> disable the promote-to-panic behavior in case it turns out to be a
> show-stopper for some user.
... we let the user turn this off, then we also have to fix this:
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-07-18 23:25:37 | Re: Have an encrypted pgpass file |
| Previous Message | Alvaro Herrera | 2018-07-18 23:16:01 | Re: Have an encrypted pgpass file |