+     <para>
+      Depending on the plan shape selected, such cases could could produce
+      wrong results, or could fail with <quote>variable not found in
+      subplan target lists</quote>.
+     </para>

"could could" seems like an accidental duplication

+     <para>
+      Disallow <literal>NOT NULL NO INHERIT</literal> constraints on
+      partitioned tables (David Rowley, Nitin Motiani)
+      <ulink url="&commit_baseurl;35f60e5ce">&sect;</ulink>
+     </para>

700b422af7e says the release note should mention more details:

    It's probably unlikely that people have commonly done this, but the
    release notes may wish to note that people should check if this has
    happened to them...


+     <para>
+      Fix <application>pg_basebackup</application>'s incorrect progress
+      reporting for incremental backups (Daria Lepikhova)
+      <ulink url="&commit_baseurl;f47c63d7a">&sect;</ulink>
+     </para>
+    </listitem>

This is a server side fix

+     <para>
+      Formerly <application>pg_dump</application> would
+      emit <literal>ALTER INDEX ... SET STATISTICS</literal> commands when
+      needed for plain indexes, but not for indexes created
+      via <literal>UNIQUE</literal> or <literal>PRIMARY KEY</literal>
+      syntax.
+     </para>
+    </listitem>

this only affects EXCLUDE constraints, because it can only be set on
an expression columns. So maybe:

Formerly pg_dump would emit ALTER INDEX ... SET STATISTICS commands
when needed for plain indexes, but not for the index underlying an
EXCLUDE constraint.


Reply via email to