Re: Proposal for changes to recovery.conf API

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for changes to recovery.conf API
Date: 2016-12-16 22:29:57
Message-ID: 20161216222957.GA19805@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 15, 2016 at 04:16:36PM -0800, Josh Berkus wrote:
> On 12/15/2016 12:54 PM, Tom Lane wrote:
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> >> On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>> You are saying this is more massive than any other change we have made
> >>> in the past? In general, what need to be documented?
> >
> >> I don't necessarily think it's because it's more massive than any chance we
> >> have made before. I think it's more that this is something that we probably
> >> should've had before, and just didn't.
> >
> >> Right now we basically have a bulletpoint list of things that are new, with
> >> a section about things that are incompatible. Having an actual section
> >> with more detailed descriptions of how to handle these changes would
> >> definitely be a win. it shouldn't *just* be for these changes of course, it
> >> should be for any other changes that are large enough to benefit from more
> >> than a oneliner about the fact that they've changed.
> >
> > Yeah, it seems to me that where this is ending up is "we may need to
> > write more in the compatibility entries than we have in the past".
> > I don't see any problem with that, particularly if someone other than
> > Bruce or me is volunteering to write it ;-)
>
> I'm up for writing it (with help from feature owners), provided that I
> don't have to spend time arguing that it's not too long, or that I
> should put it somewhere different. So can we settle the "where"
> question first?

I am fine with the release note, or the release notes plus a link to a
wiki, like we have done in the past with complex fixes in minor
releases:

https://wiki.postgresql.org/wiki/20110408pg_upgrade_fix

I think what we _don't_ want is the information _only_ in the wiki, nor
do we want to carry around migration instructions in our docs forever.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-12-16 22:30:30 Re: pg_authid.rolpassword format (was Re: Password identifiers, protocol aging and SCRAM protocol)
Previous Message Alvaro Herrera 2016-12-16 21:27:36 Re: Creating a DSA area to provide work space for parallel execution