Horton

Re: PG 12 draft release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@anarazel.de>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, Emre Hasegeli <emre@hasegeli.com>, Tomas Vondra <tv@fuzzy.cz>, Peter Geoghegan <pg@bowt.ie>, Alexander Korotkov <aekorotkov@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Surafel Temesgen <surafel3000@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-06-12T21:06:40Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: PG 12 relnotes: update wording on truncate/vacuum item

  2. docs: PG 12 relnotes, update btree items

  3. doc: PG 12 relnotes, list added snowball/FTS languages

  4. doc: PG 12 relnotes, merge new SQL partition function items

  5. docs: PG 12 release notes, support functions

  6. docs: PG 12 relnote adjustments based on feedback from Tom Lane

  7. docs: adjust RECORD PG 12 relnote item

  8. doc: adjust PG 12 relnotes item on float digit adjustment

  9. doc: adjustments for PG 12 release notes

  10. docs: fix duplicate wording in PG 12 release notes

  11. doc: properly attibute PG 12 pgbench release note item

  12. doc: PG 12 release notes: normalize attribution names

  13. Refactor the fsync queue for wider use.

  14. Add "split after new tuple" nbtree optimization.

  15. Add nbtree high key "continuescan" optimization.

  16. Allow amcheck to re-find tuples using new search.

  17. Consider secondary factors during nbtree splits.

  18. Partial implementation of SQL/JSON path language

  19. Allow extensions to generate lossy index conditions.

  20. Make TupleTableSlots extensible, finish split of existing slot type.

  21. Reduce path length for locking leaf B-tree pages during insertion

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 +