Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 04:16:53PM -0600, Justin Pryzby wrote: > On Wed, Feb 28, 2018 at 01:43:11PM -0800, Andres Freund wrote: > > 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

Re: RFC: Add 'taint' field to pg_control.

On 2018-03-07 23:34:37 -0500, Tom Lane wrote: > Craig Ringer writes: > > As I understand it, because we allow multiple Pg instances on a system, we > > identify the small sysv shmem segment we use by the postmaster's pid. If > > you remove the DirLockFile (postmaster.pid)

Re: RFC: Add 'taint' field to pg_control.

On 8 March 2018 at 12:34, Tom Lane wrote: > Craig Ringer writes: > > As I understand it, because we allow multiple Pg instances on a system, > we > > identify the small sysv shmem segment we use by the postmaster's pid. If > > you remove the

Re: RFC: Add 'taint' field to pg_control.

Craig Ringer writes: > As I understand it, because we allow multiple Pg instances on a system, we > identify the small sysv shmem segment we use by the postmaster's pid. If > you remove the DirLockFile (postmaster.pid) you remove the interlock > against starting a new

Re: RFC: Add 'taint' field to pg_control.

On 8 March 2018 at 10:18, Andres Freund wrote: > > > On March 7, 2018 5:51:29 PM PST, Craig Ringer > wrote: > >My favourite remains an organisation that kept "fixing" an issue by > >kill > >-9'ing the postmaster and removing postmaster.pid to make it

Re: RFC: Add 'taint' field to pg_control.

On March 7, 2018 5:51:29 PM PST, Craig Ringer wrote: >My favourite remains an organisation that kept "fixing" an issue by >kill >-9'ing the postmaster and removing postmaster.pid to make it start up >again. Without killing all the leftover backends. Of course, the system

Re: RFC: Add 'taint' field to pg_control.

On 8 March 2018 at 04:58, Robert Haas wrote: > On Wed, Feb 28, 2018 at 8:03 PM, Craig Ringer > wrote: > > A huge +1 from me for the idea. I can't even count the number of black > box > > "WTF did you DO?!?" servers I've looked at, where bizarre

Re: RFC: Add 'taint' field to pg_control.

On Thu, Mar 01, 2018 at 09:12:18AM +0800, Craig Ringer wrote: > On 1 March 2018 at 06:28, Justin Pryzby wrote: > > The more fine grained these are the more useful they can be: > > > > Running with fsync=off is common advice while loading, so reporting that > > "fsync=off at

Re: RFC: Add 'taint' field to pg_control.

On 1 March 2018 at 09:00, Justin Pryzby wrote: > > > > - started in single user mode or with system indices disabled? > > why? > > Some of these I suggested just as a datapoint (or other brainstorms I > couldn't > immediately reject). A cluster where someone has UPDATED

Re: RFC: Add 'taint' field to pg_control.

On 1 March 2018 at 06:28, Justin Pryzby wrote: > On Wed, Feb 28, 2018 at 02:18:12PM -0800, Andres Freund wrote: > > On 2018-02-28 17:14:18 -0500, Peter Eisentraut wrote: > > > I can see why you'd want that, but as a DBA, I don't necessarily want > > > all of that recorded,

Re: RFC: Add 'taint' field to pg_control.

On 1 March 2018 at 05:43, 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

Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 02:18:12PM -0800, Andres Freund wrote: > On 2018-02-28 17:14:18 -0500, Peter Eisentraut wrote: > > I can see why you'd want that, but as a DBA, I don't necessarily want > > all of that recorded, especially in a quasi-permanent way. > > Huh? You're arguing that we should

Re: RFC: Add 'taint' field to pg_control.

Hi, On 2018-02-28 16:16:53 -0600, Justin Pryzby wrote: Unfortunately your list seems to raise the bar to a place I don't see us going soon :( > - pg_control versions used on this cluster (hopefully a full list..obviously >not going back before PG11); That needs arbitrary much space,

Re: RFC: Add 'taint' field to pg_control.

Hi, On 2018-02-28 17:14:18 -0500, Peter Eisentraut wrote: > I can see why you'd want that, but as a DBA, I don't necessarily want > all of that recorded, especially in a quasi-permanent way. Huh? You're arguing that we should make it easier for DBAs to hide potential causes of corruption? I

Re: RFC: Add 'taint' field to pg_control.

On Wed, Feb 28, 2018 at 01:43:11PM -0800, Andres Freund wrote: > 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'

Re: RFC: Add 'taint' field to pg_control.

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.

Re: RFC: Add 'taint' field to pg_control.

On 2/28/18 16:43, Andres Freund wrote: > 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

Re: RFC: Add 'taint' field to pg_control.

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

RFC: Add 'taint' field to pg_control.

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