4242
4343 <listitem>
4444<!--
45- Author: Andres Freund <andres@anarazel.de>
46- Branch: master [18b87b201] 2022-01-13 18:13:41 -0800
47- Branch: REL_14_STABLE [dad1539ae] 2022-01-14 10:56:12 -0800
48- -->
49- <para>
50- Fix corruption of HOT chains when a RECENTLY_DEAD tuple changes
51- state to fully DEAD during page pruning (Andres Freund)
52- </para>
53-
54- <para>
55- This happens when the last transaction that could <quote>see</quote>
56- the tuple ends while the page is being pruned. It was then possible
57- to remove a tuple that is pointed to by a redirect item elsewhere on
58- the page. While that causes no immediate problem, when the item slot
59- is re-used by some new tuple, that tuple would be thought to be part
60- of the pre-existing HOT chain, creating a form of index corruption.
61- If this seems to have affected a table, <command>REINDEX</command>
62- should repair the damage.
63- </para>
64- </listitem>
65-
66- <listitem>
67- <!--
6845Author: Michael Paquier <michael@paquier.xyz>
6946Branch: master [f99870dd8] 2021-12-08 11:01:08 +0900
7047Branch: REL_14_STABLE [64ab21f0e] 2021-12-08 11:01:14 +0900
@@ -90,6 +67,30 @@ Branch: REL_12_STABLE [5ed74d874] 2021-12-08 11:01:23 +0900
9067
9168 <listitem>
9269<!--
70+ Author: Andres Freund <andres@anarazel.de>
71+ Branch: master [18b87b201] 2022-01-13 18:13:41 -0800
72+ Branch: REL_14_STABLE [dad1539ae] 2022-01-14 10:56:12 -0800
73+ -->
74+ <para>
75+ Fix corruption of HOT chains when a RECENTLY_DEAD tuple changes
76+ state to fully DEAD during page pruning (Andres Freund)
77+ </para>
78+
79+ <para>
80+ It was possible for <command>VACUUM</command> to remove a
81+ recently-dead tuple while leaving behind a redirect item that
82+ pointed to it. When the tuple's item slot is later re-used by
83+ some new tuple, that tuple would be seen as part of the
84+ pre-existing HOT chain, creating a form of index corruption.
85+ If this has happened, reindexing the table should repair the
86+ damage. However, this is an extremely low-probability scenario,
87+ so we do not recommend reindexing just on the chance that it might
88+ have happened.
89+ </para>
90+ </listitem>
91+
92+ <listitem>
93+ <!--
9394Author: Etsuro Fujita <efujita@postgresql.org>
9495Branch: master [f862d5705] 2022-02-03 15:15:00 +0900
9596Branch: REL_14_STABLE [7b0cec2fa] 2022-02-03 15:15:01 +0900
@@ -446,9 +447,11 @@ Branch: REL_10_STABLE [9211c2e38] 2022-01-15 18:30:45 +0100
446447 A previous bug fix disabled building of extended statistics for
447448 old-style inheritance trees, but it also prevented building them for
448449 partitioned tables, which was an unnecessary restriction.
449- If you have created statistics objects for partitioned tables, you
450- may wish to explicitly <command>ANALYZE</command> those tables after
451- installing this update, rather than waiting for auto-analyze to do it.
450+ This change allows <command>ANALYZE</command> to compute values for
451+ statistics objects for partitioned tables. (But note that
452+ autovacuum does not process partitioned tables as such, so you must
453+ periodically issue manual <command>ANALYZE</command> on the
454+ partitioned table if you want to maintain such statistics.)
452455 </para>
453456 </listitem>
454457
@@ -467,12 +470,10 @@ Branch: REL_10_STABLE [ff0e7c7e8] 2022-01-15 03:05:06 +0100
467470 </para>
468471
469472 <para>
470- A previous bug fix disabled building of extended statistics for
471- old-style inheritance trees, but any existing statistics data was
472- not removed, and that data would become more and more out-of-date
473- over time. Adjust the planner to ignore such data. Extended
474- statistics for the individual child tables are still built and used,
475- however.
473+ Currently, extended statistics values are only computed locally for
474+ each table, not for entire inheritance trees. However the values
475+ were mistakenly consulted when planning queries across inheritance
476+ trees, possibly resulting in worse-than-default estimates.
476477 </para>
477478 </listitem>
478479
@@ -569,9 +570,9 @@ Branch: master [f4e7ae2b8] 2021-11-20 14:29:56 -0500
569570Branch: REL_14_STABLE [6d07cbc50] 2021-11-20 14:29:56 -0500
570571-->
571572 <para>
572- Fix failure of SP-GiST indexes when indexed column's data type is
573- binary-compatible with the declared input type of the operator class
574- (Tom Lane)
573+ Fix failure of SP-GiST indexes whenthe indexed column's data type
574+ is binary-compatible with the declared input type of the operator
575+ class (Tom Lane)
575576 </para>
576577
577578 <para>
@@ -848,7 +849,7 @@ Branch: REL_10_STABLE [3bc46e4e9] 2021-11-12 14:55:32 -0500
848849 This agrees with the documented behavior, and avoids probable
849850 permissions failure if <command>SET ROLE</command> or <command>SET
850851 SESSION AUTHORIZATION</command> has been done since the session began.
851- Toreduce confusion, the role name to be acted on is now always
852+ Toprevent confusion, the role name to be acted on is now
852853 included in the password prompt.
853854 </para>
854855 </listitem>
@@ -1052,14 +1053,14 @@ Branch: REL_10_STABLE [b21986908] 2022-01-08 14:54:39 -0500
10521053
10531054 <para>
10541055 Index-only scans returned column values with trailing spaces
1055- removed, which is not the expected behavior. Thathappens because
1056- that's howit's stored in the index. This fix changes the logic to
1057- store <type>char(<replaceable>N</replaceable>)</type> values with
1058- the expected amount of space padding. The behavior of the index
1059- will not change immediately unless you <command>REINDEX</command>
1060- it; otherwise space-stripped values will be gradually replaced over
1061- time during updates. Queries that do not use index-only scan plans
1062- will be unaffected in any case.
1056+ removed, which is not the expected behavior. Thathappened because
1057+ that's howthe data was stored in the index. This fix changes the
1058+ code to store <type>char(<replaceable>N</replaceable>)</type> values
1059+ with the expected amount of space padding.
1060+ The behavior of such an index will not change immediately unless
1061+ you <command>REINDEX</command> it; otherwise space-stripped values
1062+ will be gradually replaced over time during updates. Queries that
1063+ do not use index-only scan plans will be unaffected in any case.
10631064 </para>
10641065 </listitem>
10651066