Re: PG 13 release notes, first draft - Mailing list pgsql-hackers

Hi Bruce,

On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks for this as always.

+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
+-->
+
+<para>
+Improve cases where pruning of partitions can happen (Amit Langote,
Yuzuko Hosoya, Álvaro Herrera)
+</para>

The following commit should be included with this item:

commit 489247b0e615592111226297a0564e11616361a5
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Sun Aug 4 11:18:45 2019 -0400

    Improve pruning of a default partition

Primary author for this commit and the person who raised various
problems that led to these improvements is Yuzuko Hosoya. So I think
her name should go first.

+Author: Etsuro Fujita <efujita@postgresql.org>
+2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
+-->
+
+<para>
+Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote)
+</para>

Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery of
partitionwise join code to handle FULL JOINs correctly.  Tom's rewrite
of my patch for the latter was pretty significant too, so maybe better
to list his name as well.

+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
+-->
+
+<para>
+Allow logical replication to replicate partitioned tables (Amit Langote)
+</para>
+
+</listitem>
+
+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
+-->
+
+<para>
+Allow partitioned tables to be added to replicated publications (Amit Langote)
+</para>
+
+<para>
+Partition additions/removals are replicated as well.  Previously,
partitions had to be replicated individually.  HOW IS THIS DIFFERENT
FROM THE ITEM ABOVE?
+</para>

The former is subscription-side new functionality and the latter is
publication-side and the two are somewhat independent.

Till now, logical replication could only occur between relkind 'r'
relations. So the only way to keep a given partitioned table in sync
on the two servers was to manually add the leaf partitions (of relkind
'r') to a publication and also manually keep the list of replicated
tables up to date as partitions come and go, that is, by
adding/removing them to/from the publication.

17b9e7f9f (the second item) makes it possible for the partitioned
table (relkind 'p') to be added to the publication so that individual
leaf partitions need not be manually kept in the publication.
Replication still flows between the leaf partitions (relkind 'r'
relations) though.

f1ac27bfd (the first item) makes is possible to replicate from a
regular table (relkind 'r') into a partitioned table (relkind 'p').
If a given row is replicated into a partitioned table, the
subscription worker will route it to the correct leaf partition of
that partitioned table.

+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
+-->
+
+<para>
+Allow CREATE PUBLICATION to control whether partitioned tables are
published as themselves or their ancestors (Amit Langote)
+</para>
+
+<para>
+The option is publish_via_partition_root.
+</para>

And this allows replication to optionally originate from relkind 'p'
relations on the publication server, whereas it could previously only
originate from relkind 'r' relations.  Combined with the first item,
users can now replicate between partitioned tables that have a
different set of partitions on the two servers.

Maybe it would make sense to combine the three into one item:

<para>
Add support for logical replication of partitioned tables
</para>

<para>
Logical replication can now occur between partitioned tables, where
previously it would only be allowed between regular tables. A new
publication option <literal>publish_via_partition_root</literal>
controls whether a leaf partition's changes are published as its own
or as that of the ancestor that's actually published.
</para>

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com