Release Date: 2014-03-20
This release contains a variety of fixes from 9.3.3. For information about new features in the 9.3 major release, see Section E.6.
A dump/restore is not required for those running 9.3.X.
However, the error fixed in the first changelog entry below could have resulted in corrupt data on standby servers. It may be prudent to reinitialize standby servers from fresh base backups after installing this update.
Also, if you are upgrading from a version earlier than 9.3.3, see Section E.3.
Fix WAL replay of locking an already-updated tuple (Andres Freund, Álvaro Herrera)
This error caused updated rows to not be found by index scans, resulting in inconsistent query results depending on whether an index scan was used. Subsequent processing could result in constraint violations, since the previously updated row would not be found by later index searches, thus possibly allowing conflicting rows to be inserted. Since this error is in WAL replay, it would only manifest during crash recovery or on standby servers. The improperly-replayed case most commonly arises when a table row that is referenced by a foreign-key constraint is updated concurrently with creation of a referencing row.
Restore GIN metapages unconditionally to avoid torn-page risk (Heikki Linnakangas)
Although this oversight could theoretically result in a corrupted index, it is unlikely to have caused any problems in practice, since the active part of a GIN metapage is smaller than a standard 512-byte disk sector.
Avoid race condition in checking transaction commit status during receipt of a NOTIFY message (Marko Tiikkaja)
This prevents a scenario wherein a sufficiently fast client might respond to a notification before database updates made by the notifier have become visible to the recipient.
Allow materialized views to be referenced in UPDATE and DELETE commands (Michael Paquier)
Previously such queries failed with a complaint about not being able to lock rows in the materialized view.
Allow regular-expression operators to be terminated early by query cancel requests (Tom Lane)
This prevents scenarios wherein a pathological regular expression could lock up a server process uninterruptably for a long time.
Remove incorrect code that tried to allow OVERLAPS with single-element row arguments (Joshua Yanovski)
This code never worked correctly, and since the case is neither specified by the SQL standard nor documented, it seemed better to remove it than fix it.
Avoid getting more than AccessShareLock when de-parsing a rule or view (Dean Rasheed)
This oversight resulted in pg_dump unexpectedly acquiring RowExclusiveLock locks on tables mentioned as the targets of INSERT/UPDATE/DELETE commands in rules. While usually harmless, that could interfere with concurrent transactions that tried to acquire, for example, ShareLock on those tables.
Improve performance of index endpoint probes during planning (Tom Lane)
This change fixes a significant performance problem that occurred when there were many not-yet-committed rows at the end of the index, which is a common situation for indexes on sequentially-assigned values such as timestamps or sequence-generated identifiers.
Use non-default selectivity estimates for value IN (list) and value operator ANY (array) expressions when the righthand side is a stable expression (Tom Lane)
Remove the correct per-database statistics file during DROP DATABASE (Tomas Vondra)
This fix prevents a permanent leak of statistics file space. Users who have done many DROP DATABASE commands since upgrading to PostgreSQL 9.3 may wish to check their statistics directory and delete statistics files that do not correspond to any existing database. Please note that db_0.stat should not be removed.
Fix walsender ping logic to avoid inappropriate disconnects under continuous load (Andres Freund, Heikki Linnakangas)
walsender failed to send ping messages to the client if it was constantly busy sending WAL data; but it expected to see ping responses despite that, and would therefore disconnect once wal_sender_timeout elapsed.
Fix walsender's failure to shut down cleanly when client is pg_receivexlog (Fujii Masao)
Check WAL level and hot standby parameters correctly when doing crash recovery that will be followed by archive recovery (Heikki Linnakangas)
Fix test to see if hot standby connections can be allowed immediately after a crash (Heikki Linnakangas)
Add read-only data_checksums parameter to display whether page checksums are enabled (Heikki Linnakangas)
Without this parameter, determining the state of checksum processing was difficult.
Prevent interrupts while reporting non-ERROR messages (Tom Lane)
This guards against rare server-process freezeups due to
recursive entry to
and perhaps other related problems.
Fix memory leak in PL/Perl when returning a composite result, including multiple-OUT-parameter cases (Alex Hunsaker)
Fix tracking of psql script line numbers during \copy from out-of-line data (Kumar Rajeev Rastogi, Amit Khandekar)
\copy ... from incremented the script file line number for each data line, even if the data was not coming from the script file. This mistake resulted in wrong line numbers being reported for any errors occurring later in the same script file.
Fix contrib/postgres_fdw to handle multiple join conditions properly (Tom Lane)
This oversight could result in sending WHERE clauses to the remote server for execution even though the clauses are not known to have the same semantics on the remote server (for example, clauses that use non-built-in operators). The query might succeed anyway, but it could also fail with errors from the remote server, or worse give silently wrong answers.
Prevent intermittent "could not reserve shared memory region" failures on recent Windows versions (MauMau)
Update time zone data files to tzdata release 2014a for DST law changes in Fiji and Turkey, plus historical changes in Israel and Ukraine.
Please use this form to add your own comments regarding your experience with particular features of PostgreSQL, clarifications of the documentation, or hints for other users. Please note, this is not a support forum, and your IP address will be logged. If you have a question or need help, please see the faq, try a mailing list, or join us on IRC. Note that submissions containing URLs or other keywords commonly found in 'spam' comments may be silently discarded. Please contact the webmaster if you think this is happening to you in error.
Proceed to the comment form.