|
1 | 1 | <!-- doc/src/sgml/release-8.3.sgml -->
|
2 | 2 | <!-- See header comment in release.sgml about typical markup -->
|
3 | 3 |
|
| 4 | + <sect1 id="release-8-3-18"> |
| 5 | + <title>Release 8.3.18</title> |
| 6 | + |
| 7 | + <note> |
| 8 | + <title>Release Date</title> |
| 9 | + <simpara>2012-02-27</simpara> |
| 10 | + </note> |
| 11 | + |
| 12 | + <para> |
| 13 | + This release contains a variety of fixes from 8.3.17. |
| 14 | + For information about new features in the 8.3 major release, see |
| 15 | + <xref linkend="release-8-3">. |
| 16 | + </para> |
| 17 | + |
| 18 | + <sect2> |
| 19 | + <title>Migration to Version 8.3.18</title> |
| 20 | + |
| 21 | + <para> |
| 22 | + A dump/restore is not required for those running 8.3.X. |
| 23 | + </para> |
| 24 | + |
| 25 | + <para> |
| 26 | + However, if you are upgrading from a version earlier than 8.3.17, |
| 27 | + see the release notes for 8.3.17. |
| 28 | + </para> |
| 29 | + |
| 30 | + </sect2> |
| 31 | + |
| 32 | + <sect2> |
| 33 | + <title>Changes</title> |
| 34 | + |
| 35 | + <itemizedlist> |
| 36 | + |
| 37 | + <listitem> |
| 38 | + <para> |
| 39 | + Fix btree index corruption from insertions concurrent with vacuuming |
| 40 | + (Tom Lane) |
| 41 | + </para> |
| 42 | + |
| 43 | + <para> |
| 44 | + An index page split caused by an insertion could sometimes cause a |
| 45 | + concurrently-running <command>VACUUM</> to miss removing index entries |
| 46 | + that it should remove. After the corresponding table rows are removed, |
| 47 | + the dangling index entries would cause errors (such as <quote>could not |
| 48 | + read block N in file ...</>) or worse, silently wrong query results |
| 49 | + after unrelated rows are re-inserted at the now-free table locations. |
| 50 | + This bug has been present since release 8.2, but occurs so infrequently |
| 51 | + that it was not diagnosed until now. If you have reason to suspect |
| 52 | + that it has happened in your database, reindexing the affected index |
| 53 | + will fix things. |
| 54 | + </para> |
| 55 | + </listitem> |
| 56 | + |
| 57 | + <listitem> |
| 58 | + <para> |
| 59 | + Allow non-existent values for some settings in <command>ALTER |
| 60 | + USER/DATABASE SET</> (Heikki Linnakangas) |
| 61 | + </para> |
| 62 | + |
| 63 | + <para> |
| 64 | + Allow <varname>default_text_search_config</>, |
| 65 | + <varname>default_tablespace</>, and <varname>temp_tablespaces</> to be |
| 66 | + set to names that are not known. This is because they might be known |
| 67 | + in another database where the setting is intended to be used, or for the |
| 68 | + tablespace cases because the tablespace might not be created yet. The |
| 69 | + same issue was previously recognized for <varname>search_path</>, and |
| 70 | + these settings now act like that one. |
| 71 | + </para> |
| 72 | + </listitem> |
| 73 | + |
| 74 | + <listitem> |
| 75 | + <para> |
| 76 | + Track the OID counter correctly during WAL replay, even when it wraps |
| 77 | + around (Tom Lane) |
| 78 | + </para> |
| 79 | + |
| 80 | + <para> |
| 81 | + Previously the OID counter would remain stuck at a high value until the |
| 82 | + system exited replay mode. The practical consequences of that are |
| 83 | + usually nil, but there are scenarios wherein a standby server that's |
| 84 | + been promoted to master might take a long time to advance the OID |
| 85 | + counter to a reasonable value once values are needed. |
| 86 | + </para> |
| 87 | + </listitem> |
| 88 | + |
| 89 | + <listitem> |
| 90 | + <para> |
| 91 | + Fix regular expression back-references with <literal>*</> attached |
| 92 | + (Tom Lane) |
| 93 | + </para> |
| 94 | + |
| 95 | + <para> |
| 96 | + Rather than enforcing an exact string match, the code would effectively |
| 97 | + accept any string that satisfies the pattern sub-expression referenced |
| 98 | + by the back-reference symbol. |
| 99 | + </para> |
| 100 | + |
| 101 | + <para> |
| 102 | + A similar problem still afflicts back-references that are embedded in a |
| 103 | + larger quantified expression, rather than being the immediate subject |
| 104 | + of the quantifier. This will be addressed in a future |
| 105 | + <productname>PostgreSQL</> release. |
| 106 | + </para> |
| 107 | + </listitem> |
| 108 | + |
| 109 | + <listitem> |
| 110 | + <para> |
| 111 | + Fix recently-introduced memory leak in processing of |
| 112 | + <type>inet</>/<type>cidr</> values (Heikki Linnakangas) |
| 113 | + </para> |
| 114 | + |
| 115 | + <para> |
| 116 | + A patch in the December 2011 releases of <productname>PostgreSQL</> |
| 117 | + caused memory leakage in these operations, which could be significant |
| 118 | + in scenarios such as building a btree index on such a column. |
| 119 | + </para> |
| 120 | + </listitem> |
| 121 | + |
| 122 | + <listitem> |
| 123 | + <para> |
| 124 | + Avoid double close of file handle in syslogger on Windows (MauMau) |
| 125 | + </para> |
| 126 | + |
| 127 | + <para> |
| 128 | + Ordinarily this error was invisible, but it would cause an exception |
| 129 | + when running on a debug version of Windows. |
| 130 | + </para> |
| 131 | + </listitem> |
| 132 | + |
| 133 | + <listitem> |
| 134 | + <para> |
| 135 | + Fix I/O-conversion-related memory leaks in plpgsql |
| 136 | + (Andres Freund, Jan Urbanski, Tom Lane) |
| 137 | + </para> |
| 138 | + |
| 139 | + <para> |
| 140 | + Certain operations would leak memory until the end of the current |
| 141 | + function. |
| 142 | + </para> |
| 143 | + </listitem> |
| 144 | + |
| 145 | + <listitem> |
| 146 | + <para> |
| 147 | + Improve <application>pg_dump</>'s handling of inherited table columns |
| 148 | + (Tom Lane) |
| 149 | + </para> |
| 150 | + |
| 151 | + <para> |
| 152 | + <application>pg_dump</> mishandled situations where a child column has |
| 153 | + a different default expression than its parent column. If the default |
| 154 | + is textually identical to the parent's default, but not actually the |
| 155 | + same (for instance, because of schema search path differences) it would |
| 156 | + not be recognized as different, so that after dump and restore the |
| 157 | + child would be allowed to inherit the parent's default. Child columns |
| 158 | + that are <literal>NOT NULL</> where their parent is not could also be |
| 159 | + restored subtly incorrectly. |
| 160 | + </para> |
| 161 | + </listitem> |
| 162 | + |
| 163 | + <listitem> |
| 164 | + <para> |
| 165 | + Fix <application>pg_restore</>'s direct-to-database mode for |
| 166 | + INSERT-style table data (Tom Lane) |
| 167 | + </para> |
| 168 | + |
| 169 | + <para> |
| 170 | + Direct-to-database restores from archive files made with |
| 171 | + <option>--inserts</> or <option>--column-inserts</> options fail when |
| 172 | + using <application>pg_restore</> from a release dated September or |
| 173 | + December 2011, as a result of an oversight in a fix for another |
| 174 | + problem. The archive file itself is not at fault, and text-mode |
| 175 | + output is okay. |
| 176 | + </para> |
| 177 | + </listitem> |
| 178 | + |
| 179 | + <listitem> |
| 180 | + <para> |
| 181 | + Fix error in <filename>contrib/intarray</>'s <literal>int[] & |
| 182 | + int[]</> operator (Guillaume Lelarge) |
| 183 | + </para> |
| 184 | + |
| 185 | + <para> |
| 186 | + If the smallest integer the two input arrays have in common is 1, |
| 187 | + and there are smaller values in either array, then 1 would be |
| 188 | + incorrectly omitted from the result. |
| 189 | + </para> |
| 190 | + </listitem> |
| 191 | + |
| 192 | + <listitem> |
| 193 | + <para> |
| 194 | + Fix error detection in <filename>contrib/pgcrypto</>'s |
| 195 | + <function>encrypt_iv()</> and <function>decrypt_iv()</> |
| 196 | + (Marko Kreen) |
| 197 | + </para> |
| 198 | + |
| 199 | + <para> |
| 200 | + These functions failed to report certain types of invalid-input errors, |
| 201 | + and would instead return random garbage values for incorrect input. |
| 202 | + </para> |
| 203 | + </listitem> |
| 204 | + |
| 205 | + <listitem> |
| 206 | + <para> |
| 207 | + Fix one-byte buffer overrun in <filename>contrib/test_parser</> |
| 208 | + (Paul Guyot) |
| 209 | + </para> |
| 210 | + |
| 211 | + <para> |
| 212 | + The code would try to read one more byte than it should, which would |
| 213 | + crash in corner cases. |
| 214 | + Since <filename>contrib/test_parser</> is only example code, this is |
| 215 | + not a security issue in itself, but bad example code is still bad. |
| 216 | + </para> |
| 217 | + </listitem> |
| 218 | + |
| 219 | + <listitem> |
| 220 | + <para> |
| 221 | + Use <function>__sync_lock_test_and_set()</> for spinlocks on ARM, if |
| 222 | + available (Martin Pitt) |
| 223 | + </para> |
| 224 | + |
| 225 | + <para> |
| 226 | + This function replaces our previous use of the <literal>SWPB</> |
| 227 | + instruction, which is deprecated and not available on ARMv6 and later. |
| 228 | + Reports suggest that the old code doesn't fail in an obvious way on |
| 229 | + recent ARM boards, but simply doesn't interlock concurrent accesses, |
| 230 | + leading to bizarre failures in multiprocess operation. |
| 231 | + </para> |
| 232 | + </listitem> |
| 233 | + |
| 234 | + <listitem> |
| 235 | + <para> |
| 236 | + Use <option>-fexcess-precision=standard</> option when building with |
| 237 | + gcc versions that accept it (Andrew Dunstan) |
| 238 | + </para> |
| 239 | + |
| 240 | + <para> |
| 241 | + This prevents assorted scenarios wherein recent versions of gcc will |
| 242 | + produce creative results. |
| 243 | + </para> |
| 244 | + </listitem> |
| 245 | + |
| 246 | + <listitem> |
| 247 | + <para> |
| 248 | + Allow use of threaded Python on FreeBSD (Chris Rees) |
| 249 | + </para> |
| 250 | + |
| 251 | + <para> |
| 252 | + Our configure script previously believed that this combination wouldn't |
| 253 | + work; but FreeBSD fixed the problem, so remove that error check. |
| 254 | + </para> |
| 255 | + </listitem> |
| 256 | + |
| 257 | + </itemizedlist> |
| 258 | + |
| 259 | + </sect2> |
| 260 | + </sect1> |
| 261 | + |
4 | 262 | <sect1 id="release-8-3-17">
|
5 | 263 | <title>Release 8.3.17</title>
|
6 | 264 |
|
|
0 commit comments