Re: RFC: Add 'taint' field to pg_control. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: RFC: Add 'taint' field to pg_control.
Date
Msg-id 20180228221623.fzpraykyafmff64m@alap3.anarazel.de
Whole thread Raw
In response to Re: RFC: Add 'taint' field to pg_control.  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: RFC: Add 'taint' field to pg_control.
Next
From: Justin Pryzby
Date:
Subject: Re: RFC: Add 'taint' field to pg_control.