Les versions correctives 9.3.3, 9.2.7, 9.1.12, 9.0.16 et 8.4.20 de PostgreSQL ont été publiées. Mettez à jour dès que possible ! http://www.postgresql.org/about/news/1506/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

PostgreSQL dans les média

PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.

Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.

(lien vers l'article original)

Correctifs appliqués

Robert Haas a poussé :

Bruce Momjian a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Use SnapshotDirty rather than an active snapshot to probe index endpoints. If there are lots of uncommitted tuples at the end of the index range, get_actual_variable_range() ends up fetching each one and doing an MVCC visibility check on it, until it finally hits a visible tuple. This is bad enough in isolation, considering that we don't need an exact answer only an approximate one. But because the tuples are not yet committed, each visibility check does a TransactionIdIsInProgress() test, which involves scanning the ProcArray. When multiple sessions do this concurrently, the ensuing contention results in horrid performance loss. 20X overall throughput loss on not-too-complicated queries is easy to demonstrate in the back branches (though someone's made it noticeably less bad in HEAD). We can dodge the problem fairly effectively by using SnapshotDirty rather than a normal MVCC snapshot. This will cause the index probe to take uncommitted tuples as good, so that we incur only one tuple fetch and test even if there are many such tuples. The extent to which this degrades the estimate is debatable: it's possible the result is actually a more accurate prediction than before, if the endmost tuple has become committed by the time we actually execute the query being planned. In any case, it's not very likely that it makes the estimate a lot worse. SnapshotDirty will still reject tuples that are known committed dead, so we won't give bogus answers if an invalid outlier has been deleted but not yet vacuumed from the index. (Because btrees know how to mark such tuples dead in the index, we shouldn't have a big performance problem in the case that there are many of them at the end of the range.) This consideration motivates not using SnapshotAny, which was also considered as a fix. Note: the back branches were using SnapshotNow instead of an MVCC snapshot, but the problem and solution are the same. Per performance complaints from Bartlomiej Romanski, Josh Berkus, and others. Back-patch to 9.0, where the issue was introduced (by commit 40608e7f949fb7e4025c0ddd5be01939adc79eec). http://git.postgresql.org/pg/commitdiff/fccebe421d0c410e6378fb281419442c84759213
  • Remove dependency on database encoding in citext regression test. Testing convert_to(..., 'ISO-8859-1') fails if there isn't a conversion function available from the database encoding to ISO-8859-1. This has been broken since day one, but the breakage was hidden by pg_do_encoding_conversion's failure to complain, up till commit 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7. Since the data being converted in this test is plain ASCII, no actual conversion need happen (and if it did, it would prove little about citext anyway). So that we still have some code coverage of the convert() family of functions, let's switch to using convert_from, with SQL_ASCII as the specified source encoding. Per buildfarm. http://git.postgresql.org/pg/commitdiff/1161d895d826950cbb736e5872935f3f53cc2e27
  • Allow regex operations to be terminated early by query cancel requests. The regex code didn't have any provision for query cancel; which is unsurprising given its non-Postgres origin, but still problematic since some operations can take a long time. Introduce a callback function to check for a pending query cancel or session termination request, and call it in a couple of strategic spots where we can make the regex code exit with an error indicator. If we ever actually split out the regex code as a standalone library, some additional work will be needed to let the cancel callback function be specified externally to the library. But that's straightforward (certainly so by comparison to putting the locale-dependent character classification logic on a similar arms-length basis), and there seems no need to do it right now. A bigger issue is that there may be more places than these two where we need to check for cancels. We can always add more checks later, now that the infrastructure is in place. Since there are known examples of not-terribly-long regexes that can lock up a backend for a long time, back-patch to all supported branches. I have hopes of fixing the known performance problems later, but adding query cancel ability seems like a good idea even if they were all fixed. http://git.postgresql.org/pg/commitdiff/9662143f0c35d64d7042fbeaf879df8f0b54be32

Heikki Linnakangas a poussé :

Jeff Davis a poussé :

  • Fix crash in json_to_record(). json_to_record() depends on get_call_result_type() for the tuple descriptor of the record that should be returned, but in some cases that cannot be determined. Add a guard to check if the tuple descriptor has been properly resolved, similar to other callers of get_call_result_type(). Also add guard for two other callers of get_call_result_type() in jsonfuncs.c. Although json_to_record() is the only actual bug, it's a good idea to follow convention. http://git.postgresql.org/pg/commitdiff/486ea0b19e08c10ff53e36e46209a928df048281

Alvaro Herrera a poussé :

  • Fix WAL replay of locking an updated tuple We were resetting the tuple's HEAP_HOT_UPDATED flag as well as t_ctid on WAL replay of a tuple-lock operation, which is incorrect when the tuple is already updated. Back-patch to 9.3. The clearing of both header elements was there previously, but since no update could be present on a tuple that was being locked, it was harmless. Bug reported by Peter Geoghegan and Greg Stark in CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=O67w0cSswPvV7XfUcU5g@mail.gmail.com and CAM-w4HPTOeMT4KP0OJK+mGgzgcTOtLRTvFZyvD0O4aH-7dxo3Q@mail.gmail.com respectively; diagnosis by Andres Freund. http://git.postgresql.org/pg/commitdiff/6bfa88acd3df830a5f7e8677c13512b1b50ae813
  • Allow BASE_BACKUP to be throttled. A new MAX_RATE option allows imposing a limit to the network transfer rate from the server side. This is useful to limit the stress that taking a base backup has on the server. pg_basebackup is now able to specify a value to the server, too. Author: Antonin Houska Patch reviewed by Stefan Radomski, Andres Freund, Zoltán Böszörményi, Fujii Masao, and Álvaro Herrera. http://git.postgresql.org/pg/commitdiff/ef5856fd9b77ef9d0d0c31fb314bb61bbfb1d704

Stephen Frost a poussé :

  • Various Coverity-spotted fixes A number of issues were identified by the Coverity scanner and are addressed in this patch. None of these appear to be security issues and many are mostly cosmetic changes. Short comments for each of the changes follows. Correct the semi-colon placement in be-secure.c regarding SSL retries. Remove a useless comparison-to-NULL in proc.c (value is dereferenced prior to this check and therefore can't be NULL). Add checking of chmod() return values to initdb. Fix a couple minor memory leaks in initdb. Fix memory leak in pg_ctl- involves free'ing the config file contents. Use an int to capture fgetc() return instead of an enum in pg_dump. Fix minor memory leaks in pg_dump. (note minor change to convertOperatorReference()'s API) Check fclose()/remove() return codes in psql. Check fstat(), find_my_exec() return codes in psql. Various ECPG memory leak fixes. Check find_my_exec() return in ECPG. Explicitly ignore pqFlush return in libpq error-path. Change PQfnumber() to avoid doing an strdup() when no changes required. Remove a few useless check-against-NULL's (value deref'd beforehand). Check rmtree(), malloc() results in pg_regress. Also check get_alternative_expectfile() return in pg_regress. http://git.postgresql.org/pg/commitdiff/b1aebbb6a86e96d7b8f3035ac730dfc24652496c

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Josh Berkus sent in a patch to clarify documentation for the upcoming jsonb type.
  • Christian Kruse sent in another revision of a patch to show xid and xmin in pg_stat_activity and pg_stat_replication.
  • Michael Paquier sent in two more revisions of a patch to change the pageinspect extension use the new LSN type.
  • Andres Freund sent in another flock of patches aimed at changeset extraction.
  • Christian Kruse sent in two more revisions of a patch to show relationinfo and tupleinfo of a lock to acquire.
  • Shigeru HANADA sent in a patch to fix an infelicity in the custom scan patches.
  • Pavel Stehule sent in another revision of a patch to change selfuncs to use a cached SnapshotDirty instead of repeated calls to GetActiveSnapshot().
  • Peter Eisentraut sent in a patch to correct the way Windows libraries get installed.
  • Yugo Nagata sent in another revision of a patch to implement to_regclass, etc.
  • Sergey Burladyan and Alex Hunsaker traded patches to fix a memory leak in PL/PerlU.
  • Tom Lane sent in a patch to avoid having deeply nested AND/OR trees in the parser.
  • Andrew Dunstan and Erik Rijkers sent in patches re: nested hstore and jsonb, built on same.
  • Alexander Korotkov sent in another revision of a patch to add a fast GIN scan.
  • Alvaro Herrera sent in a patch to fix an data corruption bug.
  • Noah Misch sent in another revision of a patch to fix the fact that UNION ALL on partitioned tables won't use indexes.
  • Christian Kruse sent in three more revisions of a patch to use MAP_HUGETLB where supported.
  • Michael Paquier sent in a patch to create a define macro for the LSN type's oid in pg_type.h for use by extension developers.
  • Andres Freund sent in a patch to fix an issue where VACUUM FULL/CLUSTER doesn't update pg_class's pg_class.relfrozenxid.
  • Jing Wang sent in a patch to report versions of the server of pg_dump as comments in the output.
  • Peter Eisentraut sent in another revision of a patch to add tests for client programs.
  • Fabien COELHO sent in a patch to fix an omission in pgbench's help output.
  • Dimitri Fontaine sent in two more revisions of a patch to add an extension control path.
  • Simon Riggs and Vik Fearing traded patches to reduce the lock levels needed for ALTER TABLE.
  • Alvaro Herrera and Pavel Stehule traded patches for the upcoming make_timestamp function.
  • Fabrízio de Royes Mello sent in another revision of a patch to allow storing custom reloptions.
  • Alvaro Herrera and Pavel Stehule traded patches to add --if-exists as an option for pg_dump.
  • Noah Misch sent in a patch to make "make check" harder to use as a vulnerability.
  • Kyotaro HORIGUCHI and Heikki Linnakangas traded patches to fix an issue where a hot standby doesn't come up in some situations.
  • Pavel Stehule sent in a patch to allow showing only failed queries in psql.
  • Alexander Korotkov sent in another revision of a patch to optimize the regex case for trigram indexes.
  • Sean Chittenden sent in a patch to fix an omission where pg_dump -Fd doesn't return write(2)'s return status, which was causing it to return success when it had in fact failed.
  • Pavel Stehule sent in a patch to add a --help-variables option to psql.
  • Andrew Dunstan and Ian Lawrence Barwick traded patches to add a FORCE_NULL option for copy COPY in CSV mode.