Re: PG 12 draft release notes

On 2019-05-21 00:17, Andres Freund wrote:
> <listitem>
> <!--
> Author: Peter Eisentraut <peter_e(at)gmx(dot)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(at)eisentraut(dot)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(at)eisentraut(dot)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(at)eisentraut(dot)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