From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFC: Add 'taint' field to pg_control. |
Date: | 2018-02-28 22:16:23 |
Message-ID: | 20180228221623.fzpraykyafmff64m@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-02-28 23:13:44 +0100, Tomas Vondra wrote:
>
> On 02/28/2018 10:43 PM, Andres Freund wrote:
> > Hi,
> >
> > a significant number of times during investigations of bugs I wondered
> > whether running the cluster with various settings, or various tools
> > could've caused the issue at hand. Therefore I'd like to propose adding
> > a 'tainted' field to pg_control, that contains some of the "history" of
> > the cluster. Individual bits inside that field that I can think of right
> > now are:
> > - pg_resetxlog was used non-passively on cluster
> > - ran with fsync=off
> > - ran with full_page_writes=off
> > - pg_upgrade was used
> >
> > What do others think?
> Isn't the uncertainty usually that you know one of these things happened
> on the cluster, but you don't know if that's the actual root cause?
> That's my experience, at least.
My experience is that you get a bugreport and you have no clue what
happened with the cluster. Often the "owner" doesn't have either. Then
you go through various theories and end up blaming it on one of these,
even though it's quite possibly never happened.
Of course this does *not* solve the issue when these actually
occurred. It's just a tool to narrow down possible causes / exclude
others.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2018-02-28 22:16:53 | Re: RFC: Add 'taint' field to pg_control. |
Previous Message | Peter Eisentraut | 2018-02-28 22:14:18 | Re: RFC: Add 'taint' field to pg_control. |