Re: Proposal for changes to recovery.conf API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, 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-15 20:54:31
Message-ID: 19315.1481835271@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ;-)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-15 23:25:03 Re: [sqlsmith] Failed assertion in TS_phrase_execute
Previous Message Tom Lane 2016-12-15 20:51:43 Re: New design for FK-based join selectivity estimation