| | 38 | <para> |
|---|
| | 39 | The release notes contain the significant changes in each |
|---|
| | 40 | <productname>PostgreSQL</productname> release, with major features and migration |
|---|
| | 41 | issues listed at the top. The release notes do not contain changes |
|---|
| | 42 | that affect only a few users or changes that are internal and therefore not |
|---|
| | 43 | user-visible. For example, the optimizer is improved in almost every |
|---|
| | 44 | release, but the improvements are usually observed by users as simply |
|---|
| | 45 | faster queries. |
|---|
| | 46 | </para> |
|---|
| | 47 | |
|---|
| | 48 | <para> |
|---|
| | 49 | A complete list of changes for each release can be obtained by |
|---|
| | 50 | viewing the <link linkend="cvs">CVS</link> logs for each release. |
|---|
| | 51 | The <ulink |
|---|
| | 52 | url="http://archives.postgresql.org/pgsql-committers/">pgsql-committers |
|---|
| | 53 | email list</ulink> contains all source code changes as well. There is also |
|---|
| | 54 | a <ulink url="http://developer.postgresql.org/cvsweb.cgi/pgsql/">web |
|---|
| | 55 | interface</ulink> that shows changes to specific files. |
|---|
| | 56 | <!-- we need a file containing the CVS logs for each release, and something |
|---|
| | 57 | like the SVN web interface that groups commits but has branches --> |
|---|
| | 58 | </para> |
|---|
| | 59 | |
|---|
| | 60 | <para> |
|---|
| | 61 | The name appearing next to each item represents the major developer for |
|---|
| | 62 | that item. Of course all changes involve community discussion and patch |
|---|
| | 63 | review, so each item is truly a community effort. |
|---|
| | 64 | </para> |
|---|
| | 65 | |
|---|
| | 66 | <sect1 id="release-8-1-12"> |
|---|
| | 67 | <title>Release 8.1.12</title> |
|---|
| | 68 | |
|---|
| | 69 | <note> |
|---|
| | 70 | <title>Release date</title> |
|---|
| | 71 | <simpara>2008-06-09</simpara> |
|---|
| | 72 | </note> |
|---|
| | 73 | |
|---|
| | 74 | <para> |
|---|
| | 75 | This release contains a variety of fixes from 8.1.11. |
|---|
| | 76 | For information about new features in the 8.1 major release, see |
|---|
| | 77 | <xref linkend="release-8-1"/>. |
|---|
| | 78 | </para> |
|---|
| | 79 | |
|---|
| | 80 | <sect2> |
|---|
| | 81 | <title>Migration to Version 8.1.12</title> |
|---|
| | 82 | |
|---|
| | 83 | <para> |
|---|
| | 84 | A dump/restore is not required for those running 8.1.X. |
|---|
| | 85 | However, if you are upgrading from a version earlier than 8.1.2, |
|---|
| | 86 | see the release notes for 8.1.2. |
|---|
| | 87 | </para> |
|---|
| | 88 | |
|---|
| | 89 | </sect2> |
|---|
| | 90 | |
|---|
| | 91 | <sect2> |
|---|
| | 92 | <title>Changes</title> |
|---|
| | 93 | |
|---|
| | 94 | <itemizedlist> |
|---|
| | 95 | |
|---|
| | 96 | <listitem> |
|---|
| | 97 | <para> |
|---|
| | 98 | Fix <command>ALTER TABLE ADD COLUMN ... PRIMARY KEY</command> so that the new |
|---|
| | 99 | column is correctly checked to see if it's been initialized to all |
|---|
| | 100 | non-nulls (Brendan Jurd) |
|---|
| | 101 | </para> |
|---|
| | 102 | |
|---|
| | 103 | <para> |
|---|
| | 104 | Previous versions neglected to check this requirement at all. |
|---|
| | 105 | </para> |
|---|
| | 106 | </listitem> |
|---|
| | 107 | |
|---|
| | 108 | <listitem> |
|---|
| | 109 | <para> |
|---|
| | 110 | Fix possible <command>CREATE TABLE</command> failure when inheriting the |
|---|
| | 111 | <quote>same</quote> constraint from multiple parent relations that |
|---|
| | 112 | inherited that constraint from a common ancestor (Tom) |
|---|
| | 113 | </para> |
|---|
| | 114 | </listitem> |
|---|
| | 115 | |
|---|
| | 116 | <listitem> |
|---|
| | 117 | <para> |
|---|
| | 118 | Fix conversions between ISO-8859-5 and other encodings to handle |
|---|
| | 119 | Cyrillic <quote>Yo</quote> characters (<literal>e</literal> and <literal>E</literal> with |
|---|
| | 120 | two dots) (Sergey Burladyan) |
|---|
| | 121 | </para> |
|---|
| | 122 | </listitem> |
|---|
| | 123 | |
|---|
| | 124 | <listitem> |
|---|
| | 125 | <para> |
|---|
| | 126 | Fix a few datatype input functions |
|---|
| | 127 | that were allowing unused bytes in their results to contain |
|---|
| | 128 | uninitialized, unpredictable values (Tom) |
|---|
| | 129 | </para> |
|---|
| | 130 | |
|---|
| | 131 | <para> |
|---|
| | 132 | This could lead to failures in which two apparently identical literal |
|---|
| | 133 | values were not seen as equal, resulting in the parser complaining |
|---|
| | 134 | about unmatched <literal>ORDER BY</literal> and <literal>DISTINCT</literal> |
|---|
| | 135 | expressions. |
|---|
| | 136 | </para> |
|---|
| | 137 | </listitem> |
|---|
| | 138 | |
|---|
| | 139 | <listitem> |
|---|
| | 140 | <para> |
|---|
| | 141 | Fix a corner case in regular-expression substring matching |
|---|
| | 142 | (<literal>substring(<replaceable>string</replaceable> from |
|---|
| | 143 | <replaceable>pattern</replaceable>)</literal>) (Tom) |
|---|
| | 144 | </para> |
|---|
| | 145 | |
|---|
| | 146 | <para> |
|---|
| | 147 | The problem occurs when there is a match to the pattern overall but |
|---|
| | 148 | the user has specified a parenthesized subexpression and that |
|---|
| | 149 | subexpression hasn't got a match. An example is |
|---|
| | 150 | <literal>substring('foo' from 'foo(bar)?')</literal>. |
|---|
| | 151 | This should return NULL, since <literal>(bar)</literal> isn't matched, but |
|---|
| | 152 | it was mistakenly returning the whole-pattern match instead (ie, |
|---|
| | 153 | <literal>foo</literal>). |
|---|
| | 154 | </para> |
|---|
| | 155 | </listitem> |
|---|
| | 156 | |
|---|
| | 157 | <listitem> |
|---|
| | 158 | <para> |
|---|
| | 159 | Update time zone data files to <application>tzdata</application> release 2008c (for |
|---|
| | 160 | DST law changes in Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, |
|---|
| | 161 | Argentina/San_Luis, and Chile) |
|---|
| | 162 | </para> |
|---|
| | 163 | </listitem> |
|---|
| | 164 | |
|---|
| | 165 | <listitem> |
|---|
| | 166 | <para> |
|---|
| | 167 | Fix incorrect result from <application>ecpg</application>'s |
|---|
| | 168 | <function>PGTYPEStimestamp_sub()</function> function (Michael) |
|---|
| | 169 | </para> |
|---|
| | 170 | </listitem> |
|---|
| | 171 | |
|---|
| | 172 | <listitem> |
|---|
| | 173 | <para> |
|---|
| | 174 | Fix core dump in <filename>contrib/xml2</filename>'s |
|---|
| | 175 | <function>xpath_table()</function> function when the input query returns a |
|---|
| | 176 | NULL value (Tom) |
|---|
| | 177 | </para> |
|---|
| | 178 | </listitem> |
|---|
| | 179 | |
|---|
| | 180 | <listitem> |
|---|
| | 181 | <para> |
|---|
| | 182 | Fix <filename>contrib/xml2</filename>'s makefile to not override |
|---|
| | 183 | <literal>CFLAGS</literal> (Tom) |
|---|
| | 184 | </para> |
|---|
| | 185 | </listitem> |
|---|
| | 186 | |
|---|
| | 187 | <listitem> |
|---|
| | 188 | <para> |
|---|
| | 189 | Fix <literal>DatumGetBool</literal> macro to not fail with <application>gcc</application> |
|---|
| | 190 | 4.3 (Tom) |
|---|
| | 191 | </para> |
|---|
| | 192 | |
|---|
| | 193 | <para> |
|---|
| | 194 | This problem affects <quote>old style</quote> (V0) C functions that |
|---|
| | 195 | return boolean. The fix is already in 8.3, but the need to |
|---|
| | 196 | back-patch it was not realized at the time. |
|---|
| | 197 | </para> |
|---|
| | 198 | </listitem> |
|---|
| | 199 | |
|---|
| | 200 | <listitem> |
|---|
| | 201 | <para> |
|---|
| | 202 | Fix longstanding <command>LISTEN</command>/<command>NOTIFY</command> |
|---|
| | 203 | race condition (Tom) |
|---|
| | 204 | </para> |
|---|
| | 205 | |
|---|
| | 206 | <para> |
|---|
| | 207 | In rare cases a session that had just executed a |
|---|
| | 208 | <command>LISTEN</command> might not get a notification, even though |
|---|
| | 209 | one would be expected because the concurrent transaction executing |
|---|
| | 210 | <command>NOTIFY</command> was observed to commit later. |
|---|
| | 211 | </para> |
|---|
| | 212 | |
|---|
| | 213 | <para> |
|---|
| | 214 | A side effect of the fix is that a transaction that has executed |
|---|
| | 215 | a not-yet-committed <command>LISTEN</command> command will not see any |
|---|
| | 216 | row in <structname>pg_listener</structname> for the <command>LISTEN</command>, |
|---|
| | 217 | should it choose to look; formerly it would have. This behavior |
|---|
| | 218 | was never documented one way or the other, but it is possible that |
|---|
| | 219 | some applications depend on the old behavior. |
|---|
| | 220 | </para> |
|---|
| | 221 | </listitem> |
|---|
| | 222 | |
|---|
| | 223 | <listitem> |
|---|
| | 224 | <para> |
|---|
| | 225 | Disallow <command>LISTEN</command> and <command>UNLISTEN</command> within a |
|---|
| | 226 | prepared transaction (Tom) |
|---|
| | 227 | </para> |
|---|
| | 228 | |
|---|
| | 229 | <para> |
|---|
| | 230 | This was formerly allowed but trying to do it had various unpleasant |
|---|
| | 231 | consequences, notably that the originating backend could not exit |
|---|
| | 232 | as long as an <command>UNLISTEN</command> remained uncommitted. |
|---|
| | 233 | </para> |
|---|
| | 234 | </listitem> |
|---|
| | 235 | |
|---|
| | 236 | <listitem> |
|---|
| | 237 | <para> |
|---|
| | 238 | Fix rare crash when an error occurs during a query using a hash index |
|---|
| | 239 | (Heikki) |
|---|
| | 240 | </para> |
|---|
| | 241 | </listitem> |
|---|
| | 242 | |
|---|
| | 243 | <listitem> |
|---|
| | 244 | <para> |
|---|
| | 245 | Fix input of datetime values for February 29 in years BC (Tom) |
|---|
| | 246 | </para> |
|---|
| | 247 | |
|---|
| | 248 | <para> |
|---|
| | 249 | The former coding was mistaken about which years were leap years. |
|---|
| | 250 | </para> |
|---|
| | 251 | </listitem> |
|---|
| | 252 | |
|---|
| | 253 | <listitem> |
|---|
| | 254 | <para> |
|---|
| | 255 | Fix <quote>unrecognized node type</quote> error in some variants of |
|---|
| | 256 | <command>ALTER OWNER</command> (Tom) |
|---|
| | 257 | </para> |
|---|
| | 258 | </listitem> |
|---|
| | 259 | |
|---|
| | 260 | <listitem> |
|---|
| | 261 | <para> |
|---|
| | 262 | Fix <application>pg_ctl</application> to correctly extract the postmaster's port |
|---|
| | 263 | number from command-line options (Itagaki Takahiro, Tom) |
|---|
| | 264 | </para> |
|---|
| | 265 | |
|---|
| | 266 | <para> |
|---|
| | 267 | Previously, <literal>pg_ctl start -w</literal> could try to contact the |
|---|
| | 268 | postmaster on the wrong port, leading to bogus reports of startup |
|---|
| | 269 | failure. |
|---|
| | 270 | </para> |
|---|
| | 271 | </listitem> |
|---|
| | 272 | |
|---|
| | 273 | <listitem> |
|---|
| | 274 | <para> |
|---|
| | 275 | Use <option>-fwrapv</option> to defend against possible misoptimization |
|---|
| | 276 | in recent <application>gcc</application> versions (Tom) |
|---|
| | 277 | </para> |
|---|
| | 278 | |
|---|
| | 279 | <para> |
|---|
| | 280 | This is known to be necessary when building <productname>PostgreSQL</productname> |
|---|
| | 281 | with <application>gcc</application> 4.3 or later. |
|---|
| | 282 | </para> |
|---|
| | 283 | </listitem> |
|---|
| | 284 | |
|---|
| | 285 | <listitem> |
|---|
| | 286 | <para> |
|---|
| | 287 | Fix display of constant expressions in <literal>ORDER BY</literal> |
|---|
| | 288 | and <literal>GROUP BY</literal> (Tom) |
|---|
| | 289 | </para> |
|---|
| | 290 | |
|---|
| | 291 | <para> |
|---|
| | 292 | An explictly casted constant would be shown incorrectly. This could |
|---|
| | 293 | for example lead to corruption of a view definition during |
|---|
| | 294 | dump and reload. |
|---|
| | 295 | </para> |
|---|
| | 296 | </listitem> |
|---|
| | 297 | |
|---|
| | 298 | <listitem> |
|---|
| | 299 | <para> |
|---|
| | 300 | Fix <application>libpq</application> to handle NOTICE messages correctly |
|---|
| | 301 | during COPY OUT (Tom) |
|---|
| | 302 | </para> |
|---|
| | 303 | |
|---|
| | 304 | <para> |
|---|
| | 305 | This failure has only been observed to occur when a user-defined |
|---|
| | 306 | datatype's output routine issues a NOTICE, but there is no |
|---|
| | 307 | guarantee it couldn't happen due to other causes. |
|---|
| | 308 | </para> |
|---|
| | 309 | </listitem> |
|---|
| | 310 | |
|---|
| | 311 | </itemizedlist> |
|---|
| | 312 | |
|---|
| | 313 | </sect2> |
|---|
| | 314 | </sect1> |
|---|
| | 315 | |
|---|
| | 3815 | <sect1 id="release-8-0-16"> |
|---|
| | 3816 | <title>Release 8.0.16</title> |
|---|
| | 3817 | |
|---|
| | 3818 | <note> |
|---|
| | 3819 | <title>Release date</title> |
|---|
| | 3820 | <simpara>2008-06-09</simpara> |
|---|
| | 3821 | </note> |
|---|
| | 3822 | |
|---|
| | 3823 | <para> |
|---|
| | 3824 | This release contains a variety of fixes from 8.0.15. |
|---|
| | 3825 | For information about new features in the 8.0 major release, see |
|---|
| | 3826 | <xref linkend="release-8-0"/>. |
|---|
| | 3827 | </para> |
|---|
| | 3828 | |
|---|
| | 3829 | <sect2> |
|---|
| | 3830 | <title>Migration to Version 8.0.16</title> |
|---|
| | 3831 | |
|---|
| | 3832 | <para> |
|---|
| | 3833 | A dump/restore is not required for those running 8.0.X. |
|---|
| | 3834 | However, if you are upgrading from a version earlier than 8.0.6, |
|---|
| | 3835 | see the release notes for 8.0.6. |
|---|
| | 3836 | </para> |
|---|
| | 3837 | |
|---|
| | 3838 | </sect2> |
|---|
| | 3839 | |
|---|
| | 3840 | <sect2> |
|---|
| | 3841 | <title>Changes</title> |
|---|
| | 3842 | |
|---|
| | 3843 | <itemizedlist> |
|---|
| | 3844 | |
|---|
| | 3845 | <listitem> |
|---|
| | 3846 | <para> |
|---|
| | 3847 | Fix <command>ALTER TABLE ADD COLUMN ... PRIMARY KEY</command> so that the new |
|---|
| | 3848 | column is correctly checked to see if it's been initialized to all |
|---|
| | 3849 | non-nulls (Brendan Jurd) |
|---|
| | 3850 | </para> |
|---|
| | 3851 | |
|---|
| | 3852 | <para> |
|---|
| | 3853 | Previous versions neglected to check this requirement at all. |
|---|
| | 3854 | </para> |
|---|
| | 3855 | </listitem> |
|---|
| | 3856 | |
|---|
| | 3857 | <listitem> |
|---|
| | 3858 | <para> |
|---|
| | 3859 | Fix possible <command>CREATE TABLE</command> failure when inheriting the |
|---|
| | 3860 | <quote>same</quote> constraint from multiple parent relations that |
|---|
| | 3861 | inherited that constraint from a common ancestor (Tom) |
|---|
| | 3862 | </para> |
|---|
| | 3863 | </listitem> |
|---|
| | 3864 | |
|---|
| | 3865 | <listitem> |
|---|
| | 3866 | <para> |
|---|
| | 3867 | Fix conversions between ISO-8859-5 and other encodings to handle |
|---|
| | 3868 | Cyrillic <quote>Yo</quote> characters (<literal>e</literal> and <literal>E</literal> with |
|---|
| | 3869 | two dots) (Sergey Burladyan) |
|---|
| | 3870 | </para> |
|---|
| | 3871 | </listitem> |
|---|
| | 3872 | |
|---|
| | 3873 | <listitem> |
|---|
| | 3874 | <para> |
|---|
| | 3875 | Fix a few datatype input functions |
|---|
| | 3876 | that were allowing unused bytes in their results to contain |
|---|
| | 3877 | uninitialized, unpredictable values (Tom) |
|---|
| | 3878 | </para> |
|---|
| | 3879 | |
|---|
| | 3880 | <para> |
|---|
| | 3881 | This could lead to failures in which two apparently identical literal |
|---|
| | 3882 | values were not seen as equal, resulting in the parser complaining |
|---|
| | 3883 | about unmatched <literal>ORDER BY</literal> and <literal>DISTINCT</literal> |
|---|
| | 3884 | expressions. |
|---|
| | 3885 | </para> |
|---|
| | 3886 | </listitem> |
|---|
| | 3887 | |
|---|
| | 3888 | <listitem> |
|---|
| | 3889 | <para> |
|---|
| | 3890 | Fix a corner case in regular-expression substring matching |
|---|
| | 3891 | (<literal>substring(<replaceable>string</replaceable> from |
|---|
| | 3892 | <replaceable>pattern</replaceable>)</literal>) (Tom) |
|---|
| | 3893 | </para> |
|---|
| | 3894 | |
|---|
| | 3895 | <para> |
|---|
| | 3896 | The problem occurs when there is a match to the pattern overall but |
|---|
| | 3897 | the user has specified a parenthesized subexpression and that |
|---|
| | 3898 | subexpression hasn't got a match. An example is |
|---|
| | 3899 | <literal>substring('foo' from 'foo(bar)?')</literal>. |
|---|
| | 3900 | This should return NULL, since <literal>(bar)</literal> isn't matched, but |
|---|
| | 3901 | it was mistakenly returning the whole-pattern match instead (ie, |
|---|
| | 3902 | <literal>foo</literal>). |
|---|
| | 3903 | </para> |
|---|
| | 3904 | </listitem> |
|---|
| | 3905 | |
|---|
| | 3906 | <listitem> |
|---|
| | 3907 | <para> |
|---|
| | 3908 | Update time zone data files to <application>tzdata</application> release 2008c (for |
|---|
| | 3909 | DST law changes in Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, |
|---|
| | 3910 | Argentina/San_Luis, and Chile) |
|---|
| | 3911 | </para> |
|---|
| | 3912 | </listitem> |
|---|
| | 3913 | |
|---|
| | 3914 | <listitem> |
|---|
| | 3915 | <para> |
|---|
| | 3916 | Fix incorrect result from <application>ecpg</application>'s |
|---|
| | 3917 | <function>PGTYPEStimestamp_sub()</function> function (Michael) |
|---|
| | 3918 | </para> |
|---|
| | 3919 | </listitem> |
|---|
| | 3920 | |
|---|
| | 3921 | <listitem> |
|---|
| | 3922 | <para> |
|---|
| | 3923 | Fix core dump in <filename>contrib/xml2</filename>'s |
|---|
| | 3924 | <function>xpath_table()</function> function when the input query returns a |
|---|
| | 3925 | NULL value (Tom) |
|---|
| | 3926 | </para> |
|---|
| | 3927 | </listitem> |
|---|
| | 3928 | |
|---|
| | 3929 | <listitem> |
|---|
| | 3930 | <para> |
|---|
| | 3931 | Fix <filename>contrib/xml2</filename>'s makefile to not override |
|---|
| | 3932 | <literal>CFLAGS</literal> (Tom) |
|---|
| | 3933 | </para> |
|---|
| | 3934 | </listitem> |
|---|
| | 3935 | |
|---|
| | 3936 | <listitem> |
|---|
| | 3937 | <para> |
|---|
| | 3938 | Fix <literal>DatumGetBool</literal> macro to not fail with <application>gcc</application> |
|---|
| | 3939 | 4.3 (Tom) |
|---|
| | 3940 | </para> |
|---|
| | 3941 | |
|---|
| | 3942 | <para> |
|---|
| | 3943 | This problem affects <quote>old style</quote> (V0) C functions that |
|---|
| | 3944 | return boolean. The fix is already in 8.3, but the need to |
|---|
| | 3945 | back-patch it was not realized at the time. |
|---|
| | 3946 | </para> |
|---|
| | 3947 | </listitem> |
|---|
| | 3948 | |
|---|
| | 3949 | <listitem> |
|---|
| | 3950 | <para> |
|---|
| | 3951 | Fix longstanding <command>LISTEN</command>/<command>NOTIFY</command> |
|---|
| | 3952 | race condition (Tom) |
|---|
| | 3953 | </para> |
|---|
| | 3954 | |
|---|
| | 3955 | <para> |
|---|
| | 3956 | In rare cases a session that had just executed a |
|---|
| | 3957 | <command>LISTEN</command> might not get a notification, even though |
|---|
| | 3958 | one would be expected because the concurrent transaction executing |
|---|
| | 3959 | <command>NOTIFY</command> was observed to commit later. |
|---|
| | 3960 | </para> |
|---|
| | 3961 | |
|---|
| | 3962 | <para> |
|---|
| | 3963 | A side effect of the fix is that a transaction that has executed |
|---|
| | 3964 | a not-yet-committed <command>LISTEN</command> command will not see any |
|---|
| | 3965 | row in <structname>pg_listener</structname> for the <command>LISTEN</command>, |
|---|
| | 3966 | should it choose to look; formerly it would have. This behavior |
|---|
| | 3967 | was never documented one way or the other, but it is possible that |
|---|
| | 3968 | some applications depend on the old behavior. |
|---|
| | 3969 | </para> |
|---|
| | 3970 | </listitem> |
|---|
| | 3971 | |
|---|
| | 3972 | <listitem> |
|---|
| | 3973 | <para> |
|---|
| | 3974 | Fix rare crash when an error occurs during a query using a hash index |
|---|
| | 3975 | (Heikki) |
|---|
| | 3976 | </para> |
|---|
| | 3977 | </listitem> |
|---|
| | 3978 | |
|---|
| | 3979 | <listitem> |
|---|
| | 3980 | <para> |
|---|
| | 3981 | Fix input of datetime values for February 29 in years BC (Tom) |
|---|
| | 3982 | </para> |
|---|
| | 3983 | |
|---|
| | 3984 | <para> |
|---|
| | 3985 | The former coding was mistaken about which years were leap years. |
|---|
| | 3986 | </para> |
|---|
| | 3987 | </listitem> |
|---|
| | 3988 | |
|---|
| | 3989 | <listitem> |
|---|
| | 3990 | <para> |
|---|
| | 3991 | Fix <quote>unrecognized node type</quote> error in some variants of |
|---|
| | 3992 | <command>ALTER OWNER</command> (Tom) |
|---|
| | 3993 | </para> |
|---|
| | 3994 | </listitem> |
|---|
| | 3995 | |
|---|
| | 3996 | <listitem> |
|---|
| | 3997 | <para> |
|---|
| | 3998 | Fix <application>pg_ctl</application> to correctly extract the postmaster's port |
|---|
| | 3999 | number from command-line options (Itagaki Takahiro, Tom) |
|---|
| | 4000 | </para> |
|---|
| | 4001 | |
|---|
| | 4002 | <para> |
|---|
| | 4003 | Previously, <literal>pg_ctl start -w</literal> could try to contact the |
|---|
| | 4004 | postmaster on the wrong port, leading to bogus reports of startup |
|---|
| | 4005 | failure. |
|---|
| | 4006 | </para> |
|---|
| | 4007 | </listitem> |
|---|
| | 4008 | |
|---|
| | 4009 | <listitem> |
|---|
| | 4010 | <para> |
|---|
| | 4011 | Use <option>-fwrapv</option> to defend against possible misoptimization |
|---|
| | 4012 | in recent <application>gcc</application> versions (Tom) |
|---|
| | 4013 | </para> |
|---|
| | 4014 | |
|---|
| | 4015 | <para> |
|---|
| | 4016 | This is known to be necessary when building <productname>PostgreSQL</productname> |
|---|
| | 4017 | with <application>gcc</application> 4.3 or later. |
|---|
| | 4018 | </para> |
|---|
| | 4019 | </listitem> |
|---|
| | 4020 | |
|---|
| | 4021 | <listitem> |
|---|
| | 4022 | <para> |
|---|
| | 4023 | Fix display of constant expressions in <literal>ORDER BY</literal> |
|---|
| | 4024 | and <literal>GROUP BY</literal> (Tom) |
|---|
| | 4025 | </para> |
|---|
| | 4026 | |
|---|
| | 4027 | <para> |
|---|
| | 4028 | An explictly casted constant would be shown incorrectly. This could |
|---|
| | 4029 | for example lead to corruption of a view definition during |
|---|
| | 4030 | dump and reload. |
|---|
| | 4031 | </para> |
|---|
| | 4032 | </listitem> |
|---|
| | 4033 | |
|---|
| | 4034 | <listitem> |
|---|
| | 4035 | <para> |
|---|
| | 4036 | Fix <application>libpq</application> to handle NOTICE messages correctly |
|---|
| | 4037 | during COPY OUT (Tom) |
|---|
| | 4038 | </para> |
|---|
| | 4039 | |
|---|
| | 4040 | <para> |
|---|
| | 4041 | This failure has only been observed to occur when a user-defined |
|---|
| | 4042 | datatype's output routine issues a NOTICE, but there is no |
|---|
| | 4043 | guarantee it couldn't happen due to other causes. |
|---|
| | 4044 | </para> |
|---|
| | 4045 | </listitem> |
|---|
| | 4046 | |
|---|
| | 4047 | </itemizedlist> |
|---|
| | 4048 | |
|---|
| | 4049 | </sect2> |
|---|
| | 4050 | </sect1> |
|---|
| | 4051 | |
|---|
| | 8007 | <sect1 id="release-7-4-20"> |
|---|
| | 8008 | <title>Release 7.4.20</title> |
|---|
| | 8009 | |
|---|
| | 8010 | <note> |
|---|
| | 8011 | <title>Release date</title> |
|---|
| | 8012 | <simpara>2008-06-09</simpara> |
|---|
| | 8013 | </note> |
|---|
| | 8014 | |
|---|
| | 8015 | <para> |
|---|
| | 8016 | This release contains a variety of fixes from 7.4.19. |
|---|
| | 8017 | For information about new features in the 7.4 major release, see |
|---|
| | 8018 | <xref linkend="release-7-4"/>. |
|---|
| | 8019 | </para> |
|---|
| | 8020 | |
|---|
| | 8021 | <sect2> |
|---|
| | 8022 | <title>Migration to Version 7.4.20</title> |
|---|
| | 8023 | |
|---|
| | 8024 | <para> |
|---|
| | 8025 | A dump/restore is not required for those running 7.4.X. |
|---|
| | 8026 | However, if you are upgrading from a version earlier than 7.4.11, |
|---|
| | 8027 | see the release notes for 7.4.11. |
|---|
| | 8028 | </para> |
|---|
| | 8029 | |
|---|
| | 8030 | </sect2> |
|---|
| | 8031 | |
|---|
| | 8032 | <sect2> |
|---|
| | 8033 | <title>Changes</title> |
|---|
| | 8034 | |
|---|
| | 8035 | <itemizedlist> |
|---|
| | 8036 | |
|---|
| | 8037 | <listitem> |
|---|
| | 8038 | <para> |
|---|
| | 8039 | Fix conversions between ISO-8859-5 and other encodings to handle |
|---|
| | 8040 | Cyrillic <quote>Yo</quote> characters (<literal>e</literal> and <literal>E</literal> with |
|---|
| | 8041 | two dots) (Sergey Burladyan) |
|---|
| | 8042 | </para> |
|---|
| | 8043 | </listitem> |
|---|
| | 8044 | |
|---|
| | 8045 | <listitem> |
|---|
| | 8046 | <para> |
|---|
| | 8047 | Fix a few datatype input functions |
|---|
| | 8048 | that were allowing unused bytes in their results to contain |
|---|
| | 8049 | uninitialized, unpredictable values (Tom) |
|---|
| | 8050 | </para> |
|---|
| | 8051 | |
|---|
| | 8052 | <para> |
|---|
| | 8053 | This could lead to failures in which two apparently identical literal |
|---|
| | 8054 | values were not seen as equal, resulting in the parser complaining |
|---|
| | 8055 | about unmatched <literal>ORDER BY</literal> and <literal>DISTINCT</literal> |
|---|
| | 8056 | expressions. |
|---|
| | 8057 | </para> |
|---|
| | 8058 | </listitem> |
|---|
| | 8059 | |
|---|
| | 8060 | <listitem> |
|---|
| | 8061 | <para> |
|---|
| | 8062 | Fix a corner case in regular-expression substring matching |
|---|
| | 8063 | (<literal>substring(<replaceable>string</replaceable> from |
|---|
| | 8064 | <replaceable>pattern</replaceable>)</literal>) (Tom) |
|---|
| | 8065 | </para> |
|---|
| | 8066 | |
|---|
| | 8067 | <para> |
|---|
| | 8068 | The problem occurs when there is a match to the pattern overall but |
|---|
| | 8069 | the user has specified a parenthesized subexpression and that |
|---|
| | 8070 | subexpression hasn't got a match. An example is |
|---|
| | 8071 | <literal>substring('foo' from 'foo(bar)?')</literal>. |
|---|
| | 8072 | This should return NULL, since <literal>(bar)</literal> isn't matched, but |
|---|
| | 8073 | it was mistakenly returning the whole-pattern match instead (ie, |
|---|
| | 8074 | <literal>foo</literal>). |
|---|
| | 8075 | </para> |
|---|
| | 8076 | </listitem> |
|---|
| | 8077 | |
|---|
| | 8078 | <listitem> |
|---|
| | 8079 | <para> |
|---|
| | 8080 | Fix incorrect result from <application>ecpg</application>'s |
|---|
| | 8081 | <function>PGTYPEStimestamp_sub()</function> function (Michael) |
|---|
| | 8082 | </para> |
|---|
| | 8083 | </listitem> |
|---|
| | 8084 | |
|---|
| | 8085 | <listitem> |
|---|
| | 8086 | <para> |
|---|
| | 8087 | Fix <literal>DatumGetBool</literal> macro to not fail with <application>gcc</application> |
|---|
| | 8088 | 4.3 (Tom) |
|---|
| | 8089 | </para> |
|---|
| | 8090 | |
|---|
| | 8091 | <para> |
|---|
| | 8092 | This problem affects <quote>old style</quote> (V0) C functions that |
|---|
| | 8093 | return boolean. The fix is already in 8.3, but the need to |
|---|
| | 8094 | back-patch it was not realized at the time. |
|---|
| | 8095 | </para> |
|---|
| | 8096 | </listitem> |
|---|
| | 8097 | |
|---|
| | 8098 | <listitem> |
|---|
| | 8099 | <para> |
|---|
| | 8100 | Fix longstanding <command>LISTEN</command>/<command>NOTIFY</command> |
|---|
| | 8101 | race condition (Tom) |
|---|
| | 8102 | </para> |
|---|
| | 8103 | |
|---|
| | 8104 | <para> |
|---|
| | 8105 | In rare cases a session that had just executed a |
|---|
| | 8106 | <command>LISTEN</command> might not get a notification, even though |
|---|
| | 8107 | one would be expected because the concurrent transaction executing |
|---|
| | 8108 | <command>NOTIFY</command> was observed to commit later. |
|---|
| | 8109 | </para> |
|---|
| | 8110 | |
|---|
| | 8111 | <para> |
|---|
| | 8112 | A side effect of the fix is that a transaction that has executed |
|---|
| | 8113 | a not-yet-committed <command>LISTEN</command> command will not see any |
|---|
| | 8114 | row in <structname>pg_listener</structname> for the <command>LISTEN</command>, |
|---|
| | 8115 | should it choose to look; formerly it would have. This behavior |
|---|
| | 8116 | was never documented one way or the other, but it is possible that |
|---|
| | 8117 | some applications depend on the old behavior. |
|---|
| | 8118 | </para> |
|---|
| | 8119 | </listitem> |
|---|
| | 8120 | |
|---|
| | 8121 | <listitem> |
|---|
| | 8122 | <para> |
|---|
| | 8123 | Fix display of constant expressions in <literal>ORDER BY</literal> |
|---|
| | 8124 | and <literal>GROUP BY</literal> (Tom) |
|---|
| | 8125 | </para> |
|---|
| | 8126 | |
|---|
| | 8127 | <para> |
|---|
| | 8128 | An explictly casted constant would be shown incorrectly. This could |
|---|
| | 8129 | for example lead to corruption of a view definition during |
|---|
| | 8130 | dump and reload. |
|---|
| | 8131 | </para> |
|---|
| | 8132 | </listitem> |
|---|
| | 8133 | |
|---|
| | 8134 | <listitem> |
|---|
| | 8135 | <para> |
|---|
| | 8136 | Fix <application>libpq</application> to handle NOTICE messages correctly |
|---|
| | 8137 | during COPY OUT (Tom) |
|---|
| | 8138 | </para> |
|---|
| | 8139 | |
|---|
| | 8140 | <para> |
|---|
| | 8141 | This failure has only been observed to occur when a user-defined |
|---|
| | 8142 | datatype's output routine issues a NOTICE, but there is no |
|---|
| | 8143 | guarantee it couldn't happen due to other causes. |
|---|
| | 8144 | </para> |
|---|
| | 8145 | </listitem> |
|---|
| | 8146 | |
|---|
| | 8147 | </itemizedlist> |
|---|
| | 8148 | |
|---|
| | 8149 | </sect2> |
|---|
| | 8150 | </sect1> |
|---|
| | 8151 | |
|---|
