E.214. Release 8.1.12
Release date: never released
This release contains a variety of fixes from 8.1.11. For information about new features in the 8.1 major release, see Section E.226 .
E.214.1. Migration to Version 8.1.12
A dump/restore is not required for those running 8.1.X. However, if you are upgrading from a version earlier than 8.1.2, see Section E.224 .
E.214.2. Changes
-
Fix
ALTER TABLE ADD COLUMN ... PRIMARY KEY
so that the new column is correctly checked to see if it's been initialized to all non-nulls (Brendan Jurd)Previous versions neglected to check this requirement at all.
-
Fix possible
CREATE TABLE
failure when inheriting the " same " constraint from multiple parent relations that inherited that constraint from a common ancestor (Tom) -
Fix conversions between ISO-8859-5 and other encodings to handle Cyrillic " Yo " characters (
e
andE
with two dots) (Sergey Burladyan) -
Fix a few datatype input functions that were allowing unused bytes in their results to contain uninitialized, unpredictable values (Tom)
This could lead to failures in which two apparently identical literal values were not seen as equal, resulting in the parser complaining about unmatched
ORDER BY
andDISTINCT
expressions. -
Fix a corner case in regular-expression substring matching (
substring(
) (Tom)string
frompattern
)The problem occurs when there is a match to the pattern overall but the user has specified a parenthesized subexpression and that subexpression hasn't got a match. An example is
substring('foo' from 'foo(bar)?')
. This should return NULL, since(bar)
isn't matched, but it was mistakenly returning the whole-pattern match instead (ie,foo
). -
Update time zone data files to tzdata release 2008c (for DST law changes in Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis, and Chile)
-
Fix incorrect result from ecpg 's
PGTYPEStimestamp_sub()
function (Michael) -
Fix core dump in
contrib/xml2
'sxpath_table()
function when the input query returns a NULL value (Tom) -
Fix
contrib/xml2
's makefile to not overrideCFLAGS
(Tom) -
Fix
DatumGetBool
macro to not fail with gcc 4.3 (Tom)This problem affects " old style " (V0) C functions that return boolean. The fix is already in 8.3, but the need to back-patch it was not realized at the time.
-
Fix longstanding
LISTEN
/NOTIFY
race condition (Tom)In rare cases a session that had just executed a
LISTEN
might not get a notification, even though one would be expected because the concurrent transaction executingNOTIFY
was observed to commit later.A side effect of the fix is that a transaction that has executed a not-yet-committed
LISTEN
command will not see any row inpg_listener
for theLISTEN
, should it choose to look; formerly it would have. This behavior was never documented one way or the other, but it is possible that some applications depend on the old behavior. -
Disallow
LISTEN
andUNLISTEN
within a prepared transaction (Tom)This was formerly allowed but trying to do it had various unpleasant consequences, notably that the originating backend could not exit as long as an
UNLISTEN
remained uncommitted. -
Fix rare crash when an error occurs during a query using a hash index (Heikki)
-
Fix input of datetime values for February 29 in years BC (Tom)
The former coding was mistaken about which years were leap years.
-
Fix " unrecognized node type " error in some variants of
ALTER OWNER
(Tom) -
Fix pg_ctl to correctly extract the postmaster's port number from command-line options (Itagaki Takahiro, Tom)
Previously,
pg_ctl start -w
could try to contact the postmaster on the wrong port, leading to bogus reports of startup failure. -
Use
-fwrapv
to defend against possible misoptimization in recent gcc versions (Tom)This is known to be necessary when building PostgreSQL with gcc 4.3 or later.
-
Fix display of constant expressions in
ORDER BY
andGROUP BY
(Tom)An explicitly casted constant would be shown incorrectly. This could for example lead to corruption of a view definition during dump and reload.
-
Fix libpq to handle NOTICE messages correctly during COPY OUT (Tom)
This failure has only been observed to occur when a user-defined datatype's output routine issues a NOTICE, but there is no guarantee it couldn't happen due to other causes.