On Tue, May 21, 2019 at 12:57:56PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-21 15:47:34 -0400, Bruce Momjian wrote:
> > On Mon, May 20, 2019 at 03:17:19PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > Note that I've added a few questions to individuals involved with
> > > specific points. If you're in the To: list, please search for your name.
> > >
> > >
> > > On 2019-05-11 16:33:24 -0400, Bruce Momjian wrote:
> > > > I have posted a draft copy of the PG 12 release notes here:
> > > >
> > > > http://momjian.us/pgsql_docs/release-12.html
> > > > They are committed to git.
> > >
> > > Thanks!
> > >
> > > <title>Migration to Version 12</title>
> > >
> > > There's a number of features in the compat section that are more general
> > > improvements with a side of incompatibility. Won't it be confusing to
> > > e.g. have have the ryu floating point conversion speedups in the compat
> > > section, but not in the "General Performance" section?
> >
> > Yes, it can be. What I did with the btree item was to split out the max
> > length change with the larger changes. We can do the same for other
> > items. As you rightly stated, it is for cases where the incompatibility
> > is minor compared to the change. Do you have a list of the ones that
> > need this treatment?
>
> I was concretely thinking of:
> - floating point output changes, which are primarily about performance
If we split out the compatibility change, we don't have much left but
"performance", and that doesn't seem long enough for an entry.
> - recovery.conf changes where I'd merge:
> - Do not allow multiple different recovery_target specificatios
> - Allow some recovery parameters to be changed with reload
> - Cause recovery to advance to the latest timeline by default
> - Add an explicit value of current for guc-recovery-target-time
> into on entry on the feature side.
>
> After having to move recovery settings to a different file, disallowing
> multiple targets isn't really a separate config break imo. And all the
> other changes are also fallout from the recovery.conf GUCification.
Even though we moved the recovery.conf values into postgresql.conf, I
think people will assume they just behave the same and copy them into
the new file. If their behavior changes, they need to know that
explicitly.
--
Bruce Momjian <bruce@momjian.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 +