From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7648: Momentary index corruption while in hot standby |
Date: | 2012-11-10 11:47:28 |
Message-ID: | CAEYLb_XRmSyeTaW=CAbMWkY=2x4fDgRXJ2bEi55VjRoJ1oY4dQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 10 November 2012 00:29, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> Me too. Database clients finding these unambiguously platform-level
> problems and being relied upon to report them to receive treatment is
> a long-standing embarrassment to me. However, I've been way too
> swamped to even start thinking of how one would disentangle error
> reporting suitable for physical issues from logical issues.
I complained about this a few months ago (and a few months before
that), and the upshot was that we kicked around a few ideas and were
able to outline a useful API [1]. The idea here was to derive what I
called magnitude from SQLSTATE. In other words, we'd represent how
routine or non-routine a particular error message was (the "wake me up
in the middle of the night" factor). Severity levels don't and cannot
capture this, since for example a FATAL error occurs in the event of
failed authentication, whereas ERRORs (technically a lesser severity)
may occur in far more serious situations that a Postgres DBA can
reasonably hope to never see, with problems that indicate data
corruption, for example.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-10 15:20:24 | Re: BUG #7644: Missing implicit types of Result and failing type-conversion |
Previous Message | Daniel Farina | 2012-11-10 00:29:27 | Re: BUG #7648: Momentary index corruption while in hot standby |