Horton

Re: PG 12 draft release notes

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>, Bruce Momjian <bruce@momjian.us>, 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>, Tom Lane <tgl@sss.pgh.pa.us>, Surafel Temesgen <surafel3000@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-21T13:49:18Z
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 2019-05-21 00:17, Andres Freund wrote:
>       <listitem>
> <!--
> Author: Peter Eisentraut <peter_e@gmx.net>
> 2018-11-14 [1b5d797cd] Lower lock level for renaming indexes
> -->
> 
>        <para>
>         Reduce locking requirements for index renaming (Peter Eisentraut)
>        </para>
>       </listitem>
> 
> Should we specify the newly required lock level? Because it's quire
> relevant for users what exactly they're now able to do concurrently in
> operation?

Yes, more information is in the commit message.  We could expand the
release note item with:

"""
Renaming an index now requires only a ShareUpdateExclusiveLock instead
of a AccessExclusiveLock.  This allows index renaming without blocking
access to the table.
"""

Note also that this functionality later became part of REINDEX
CONCURRENTLY, which is presumably where most people will make use of it.


>      <listitem>
> <!--
> Author: Peter Eisentraut <peter@eisentraut.org>
> 2019-01-11 [ff8530605] Add value 'current' for recovery_target_timeline
> -->
> 
>       <para>
>        Add an explicit value of <literal>current</literal> for <xref
>        linkend="guc-recovery-target-time"/> (Peter Eisentraut)
>       </para>
>      </listitem>
> 
> Seems like this should be combined with the earlier "Cause recovery to
> advance to the latest timeline by default" entry.

It could be combined or kept separate or not mentioned at all.  Either
way is fine.


>      <listitem>
> <!--
> Author: Peter Eisentraut <peter@eisentraut.org>
> 2019-03-30 [fc22b6623] Generated columns
> -->
> 
>       <para>
>        Add support for <link linkend="sql-createtable">generated
>        columns</link> (Peter Eisentraut)
>       </para>
> 
>       <para>
>        Rather than storing a value only at row creation time, generated
>        columns are also modified during updates, and can reference other
>        table columns.
>       </para>
>      </listitem>
> 
> I find this description confusing. How about cribbing from the commit?
> Roughly like
> 
>     This allows creating columns that are computed from expressions,
>     including references to other columns in the same table, rather than
>     having to be specified by the inserter/updater.

Yeah, that's better.

> Think we also ought to mention that this is only stored generated
> columns, given that the SQL feature also includes virtual columns?

The SQL standard doesn't specify whether generated columns are stored,
but reading between the lines suggest that they expect them to be.  So
we don't need to get into more detail there in the release notes.  The
main documentation does address this point.


>      <listitem>
> <!--
> Author: Peter Eisentraut <peter@eisentraut.org>
> 2019-03-19 [590a87025] Ignore attempts to add TOAST table to shared or catalog 
> -->
> 
>       <para>
>        Allow modifications of system tables using <xref
>        linkend="sql-altertable"/> (Peter Eisentraut)
>       </para>
> 
>       <para>
>        This allows modifications of <literal>reloptions</literal> and
>        autovacuum settings.
>       </para>
>      </listitem>
> 
> I think the first paragraph is a bit dangerous. This does *not*
> generally allow modifications of system tables using ALTER TABLE.

Yes, it's overly broad.  The second paragraph is really the gist of the
change, so we could write

    Allow modifications of reloptions of system tables


-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services