<sect1 id="release-10-3">

<title>Release 10.3</title>

<formalpara>

<title>Release date:</title>

<para>2018-03-01</para>

</formalpara>

<para>

This release contains a variety of fixes from 10.2.

For information about new features in major release 10, see

<xref linkend="release-10">.

</para>

<sect2>

<title>Migration to Version 10.3</title>

<para>

A dump/restore is not required for those running 10.X.

</para>

<para>

However, if you are upgrading from a version earlier than 10.2,

see <xref linkend="release-10-2">.

</para>

</sect2>

<sect2>

<title>Changes</title>

<itemizedlist>

<listitem>

<!--

Author: Peter Eisentraut <peter_e@gmx.net>

Branch: master [bc1adc651] 2018-02-23 22:13:21 -0500

Branch: REL_10_STABLE [b9bf23abb] 2018-02-23 22:09:26 -0500

-->

<para>

Prevent logical replication from trying to ship changes for

unpublishable relations (Peter Eisentraut)

</para>

<para>

A publication marked <literal>FOR ALL TABLES</literal> would

incorrectly ship changes in materialized views

and <structname>information_schema</structname> tables, which are

supposed to be omitted from the change stream.

</para>

<para>

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [159efe4af] 2018-02-19 16:00:31 -0500

Branch: REL_10_STABLE [517e0fe86] 2018-02-19 16:00:18 -0500

Branch: REL9_6_STABLE [795f2112e] 2018-02-19 16:00:18 -0500

Branch: REL9_5_STABLE [340d63bfb] 2018-02-19 16:00:18 -0500

Branch: REL9_4_STABLE [e11b6488e] 2018-02-19 16:00:18 -0500

Branch: REL9_3_STABLE [ea6d67cf8] 2018-02-19 16:00:18 -0500

-->

<para>

Fix misbehavior of concurrent-update rechecks with CTE references

appearing in subplans (Tom Lane)

</para>

<para>

If a CTE (<literal>WITH</literal> clause reference) is used in an

InitPlan or SubPlan, and the query requires a recheck due to trying

to update or lock a concurrently-updated row, incorrect results could

be obtained.

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [9afd513df] 2018-02-23 13:47:33 -0500

Branch: REL_10_STABLE [c458970ad] 2018-02-23 13:47:33 -0500

Branch: REL9_6_STABLE [e7c02a54a] 2018-02-23 13:47:33 -0500

Branch: REL9_5_STABLE [7dc5f316f] 2018-02-23 13:47:33 -0500

Branch: REL9_4_STABLE [f6dd08489] 2018-02-23 13:47:33 -0500

Branch: REL9_3_STABLE [71a0d0c5a] 2018-02-23 13:47:33 -0500

-->

<para>

Fix planner failures with overlapping mergejoin clauses in an outer

join (Tom Lane)

</para>

<para>

These mistakes led to <quote>left and right pathkeys do not match in

mergejoin</quote> or <quote>outer pathkeys do not match

mergeclauses</quote> planner errors in corner cases.

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [38b41f182] 2018-02-21 18:40:24 -0500

Branch: REL_10_STABLE [5ab5d21aa] 2018-02-21 18:40:24 -0500

Branch: REL9_6_STABLE [66e203c85] 2018-02-21 18:40:24 -0500

Branch: REL9_5_STABLE [9936f1499] 2018-02-21 18:40:24 -0500

Branch: REL9_4_STABLE [2d12c5593] 2018-02-21 18:40:24 -0500

Branch: REL9_3_STABLE [d3b0a23a2] 2018-02-21 18:40:24 -0500

-->

<para>

Repair <application>pg_upgrade</application>'s failure to

preserve <structfield>relfrozenxid</structfield> for materialized

views (Tom Lane, Andres Freund)

</para>

<para>

This oversight could lead to data corruption in materialized views

after an upgrade, manifesting as <quote>could not access status of

transaction</quote> or <quote>found xmin from before

relfrozenxid</quote> errors. The problem would be more likely to

occur in seldom-refreshed materialized views, or ones that were

maintained only with <command>REFRESH MATERIALIZED VIEW

CONCURRENTLY</command>.

</para>

<para>

If such corruption is observed, it can be repaired by refreshing the

materialized view (without <literal>CONCURRENTLY</literal>).

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [3486bcf9e] 2018-02-20 11:23:42 -0500

Branch: REL_10_STABLE [6753f6c41] 2018-02-20 11:23:34 -0500

-->

<para>

Fix incorrect <application>pg_dump</application> output for some

non-default sequence limit values (Alexey Bashtanov)

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [5c9f2564f] 2018-02-11 13:24:15 -0500

Branch: REL_10_STABLE [1298fccef] 2018-02-11 13:24:15 -0500

-->

<para>

Fix <application>pg_dump</application>'s mishandling

of <literal>STATISTICS</literal> objects (Tom Lane)

</para>

<para>

An extended statistics object's schema was mislabeled in the dump's

table of contents, possibly leading to the wrong results in a

schema-selective restore. Its ownership was not correctly restored,

either. Also, change the logic so that statistics objects are

dumped/restored, or not, as independent objects rather than tying

them to the dump/restore decision for the table they are on. The

original definition could not scale to the planned future extension to

cross-table statistics.

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [e748e902d] 2018-02-14 14:47:18 -0500

Branch: REL_10_STABLE [4081e1136] 2018-02-14 14:47:18 -0500

Branch: REL9_6_STABLE [0a2381d13] 2018-02-14 14:47:18 -0500

Branch: REL9_5_STABLE [db1c597f3] 2018-02-14 14:47:18 -0500

Branch: REL9_4_STABLE [bd8718637] 2018-02-14 14:47:18 -0500

Branch: REL9_3_STABLE [457e9e88e] 2018-02-14 14:47:18 -0500

-->

<para>

Fix incorrect reporting of PL/Python function names in

error <literal>CONTEXT</literal> stacks (Tom Lane)

</para>

<para>

An error occurring within a nested PL/Python function call (that is,

one reached via a SPI query from another PL/Python function) would

result in a stack trace showing the inner function's name twice,

rather than the expected results. Also, an error in a nested

PL/Python <literal>DO</literal> block could result in a null pointer

dereference crash on some platforms.

</para>

</listitem>

<listitem>

<!--

Author: Tom Lane <tgl@sss.pgh.pa.us>

Branch: master [8af87f411] 2018-02-23 14:39:17 -0500

Branch: REL_10_STABLE [0222e897d] 2018-02-23 14:39:18 -0500

Branch: REL9_6_STABLE [be87cd2a0] 2018-02-23 14:39:20 -0500

Branch: REL9_5_STABLE [753875ed4] 2018-02-23 14:39:21 -0500

Branch: REL9_4_STABLE [3ba503bde] 2018-02-23 14:39:22 -0500

Branch: REL9_3_STABLE [a7a6051cf] 2018-02-23 14:39:23 -0500

-->

<para>

Allow <filename>contrib/auto_explain</filename>'s

<varname>log_min_duration</varname> setting to range up

to <literal>INT_MAX</literal>, or about 24 days instead of 35 minutes

(Tom Lane)

</para>

</listitem>

<listitem>

<!--

Author: Robert Haas <rhaas@postgresql.org>

Branch: master [935dee9ad] 2018-02-09 15:54:45 -0500

Author: Andres Freund <andres@anarazel.de>

Branch: REL_10_STABLE [2ff2baa22] 2018-02-22 12:54:45 -0800

Branch: REL9_6_STABLE [83fce670e] 2018-02-22 12:58:43 -0800

-->

<para>

Mark assorted GUC variables as <literal>PGDLLIMPORT</literal>, to

ease porting extension modules to Windows (Metin Doslu)

</para>

</listitem>

</itemizedlist>

</sect2>

</sect1>

<sect1 id="release-9-3-22">

<title>Release 9.3.22</title>

<formalpara>

<title>Release date:</title>

<para>2018-03-01</para>

</formalpara>

<para>

This release contains a variety of fixes from 9.3.21.

For information about new features in the 9.3 major release, see

<xref linkend="release-9-3">.

</para>

<sect2>

<title>Migration to Version 9.3.22</title>

<para>

A dump/restore is not required for those running 9.3.X.

</para>

<para>

However, if you are upgrading from a version earlier than 9.3.18,

see <xref linkend="release-9-3-18">.

</para>

</sect2>

<sect2>

<title>Changes</title>

<itemizedlist>

<listitem>

<para>

Fix misbehavior of concurrent-update rechecks with CTE references

appearing in subplans (Tom Lane)

</para>

<para>

If a CTE (<literal>WITH</literal> clause reference) is used in an

InitPlan or SubPlan, and the query requires a recheck due to trying

to update or lock a concurrently-updated row, incorrect results could

be obtained.

</para>

</listitem>

<listitem>

<para>

Fix planner failures with overlapping mergejoin clauses in an outer

join (Tom Lane)

</para>

<para>

These mistakes led to <quote>left and right pathkeys do not match in

mergejoin</quote> or <quote>outer pathkeys do not match

mergeclauses</quote> planner errors in corner cases.

</para>

</listitem>

<listitem>

<para>

Repair <application>pg_upgrade</application>'s failure to

preserve <structfield>relfrozenxid</structfield> for materialized

views (Tom Lane, Andres Freund)

</para>

<para>

This oversight could lead to data corruption in materialized views

after an upgrade, manifesting as <quote>could not access status of

transaction</quote> or <quote>found xmin from before

relfrozenxid</quote> errors. The problem would be more likely to

occur in seldom-refreshed materialized views, or ones that were

maintained only with <command>REFRESH MATERIALIZED VIEW

CONCURRENTLY</command>.

</para>

<para>

If such corruption is observed, it can be repaired by refreshing the

materialized view (without <literal>CONCURRENTLY</literal>).

</para>

</listitem>

<listitem>

<para>

Fix incorrect reporting of PL/Python function names in

error <literal>CONTEXT</literal> stacks (Tom Lane)

</para>

<para>

An error occurring within a nested PL/Python function call (that is,

one reached via a SPI query from another PL/Python function) would

result in a stack trace showing the inner function's name twice,

rather than the expected results. Also, an error in a nested

PL/Python <literal>DO</literal> block could result in a null pointer

dereference crash on some platforms.

</para>

</listitem>

<listitem>

<para>

Allow <filename>contrib/auto_explain</filename>'s

<varname>log_min_duration</varname> setting to range up

to <literal>INT_MAX</literal>, or about 24 days instead of 35 minutes

(Tom Lane)

</para>

</listitem>

</itemizedlist>

</sect2>

</sect1>