Re: MultiXact member wraparound protections are now enabled

From: Noah Misch <noah(at)leadboat(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MultiXact member wraparound protections are now enabled
Date: 2015-07-28 03:23:16
Message-ID: 20150728032316.GA1546507@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 27, 2015 at 07:59:40AM +0100, Simon Riggs wrote:
> On 26 July 2015 at 20:15, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > On Fri, Jul 24, 2015 at 09:14:09PM -0400, Peter Eisentraut wrote:
> > > On 7/22/15 4:45 PM, Robert Haas wrote:
> > > > But it seemed to me that this could be rather confusing. I thought it
> > > > would be better to be explicit about whether the protections are
> > > > enabled in all cases. That way, (1) if you see the message saying
> > > > they are enabled, they are enabled; (2) if you see the message saying
> > > > they are disabled, they are disabled; and (3) if you see neither
> > > > message, your version does not have those protections.
> > >
> > > But this is not documented, AFAICT, so I don't think anyone is going to
> > > be able to follow that logic. I don't see anything in the release notes
> > > saying, look for this message to see how this applies to you, or
> > whatever.
> >
> > I supported inclusion of the message, because it has good potential to help
> > experts studying historical logs to find the root cause of data corruption.
> > The complex histories of clusters showing corruption from this series of
> > bugs
> > have brought great expense to the task of debugging new reports. Given a
> > cluster having full mxact wraparound protections since last corruption-free
> > backup (or since initdb), one can rule out some causes.
>
>
> Would it be better to replace it with a less specific and more generally
> useful message?
>
> For example, Server started with release X.y.z
> from which we could infer various useful things.

That message does sound generally useful, but we couldn't infer $subject from
it. While the $subject message appears at startup in simple cases, autovacuum
prerequisite work can delay it indefinitely.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-07-28 03:24:35 Re: proposal: multiple psql option -c
Previous Message Alvaro Herrera 2015-07-28 03:20:36 Re: Planner debug views