La 6ème conférence annuelle Highload++ aura lieu les 22 & 23 octobre 2012 à Moscou (Russie) : http://highload.co/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

  • La 6ème conférence annuelle Highload++ aura lieu les 22 & 23 octobre 2012 à Moscou (Russie) : http://highload.co/
  • La PostgreSQL Conference Europe 2012 aura lieu à Prague, République Tchèque, du 23 au 26 octobre : http://2012.pgconf.eu/
  • Il y aura un PGDay également le 9 novembre 2012 à l'USP de São Paulo : http://www.postgresql.org.br/node/16949
  • Le PgDay argentin 2012 se tiendra à l'Université Nationale de Quilmes, à Bernal près de Buenos Aires, le 13 novembre. Les sujets couverts concerneront aussi bien les utilisateurs, développeurs et contributeurs, que les décideurs et hauts responsables. Pour plus d'informations à propos de la conférence, consultez le site suivant : http://www.pgday.com.ar/quilmes2012?lang=en
  • Le PGDay équatorien de cette année se tiendra à Quito le 17 novembre. L'appel à conférenciers est lancé jusqu'au 10 octobre. Envoyez vos propositions à Jaime Casanova : jaime <AT> 2ndquadrant <DOT> com : https://wiki.postgresql.org/wiki/PGDay_Ecuador_2012
  • La sixième édition du PGDay italien aura lieu à Prato, Toscane, le 23 novembre 2012. Un appel international à conférenciers est lancé, conférences et présentations en anglais sont acceptées. Informations anglophones sur le processus de candidature disponibles ci-après : http://2012.pgday.it/call-for-papers/international-call-for-papers/

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

Heikki Linnakangas a poussé :

Tom Lane a poussé :

  • alter_generic regression test cannot run concurrently with privileges test. ... because the latter plays games with the privileges for language SQL. It looks like running alter_generic in parallel with "misc" is OK though. Also, adjust serial_schedule to maintain the same test ordering (up to parallelism) as parallel_schedule. http://git.postgresql.org/pg/commitdiff/b72bd3d1c65886c21a961830325f11a3f7a41799
  • Close un-owned SMgrRelations at transaction end. If an SMgrRelation is not "owned" by a relcache entry, don't allow it to live past transaction end. This design allows the same SMgrRelation to be used for blind writes of multiple blocks during a transaction, but ensures that we don't hold onto such an SMgrRelation indefinitely. Because an SMgrRelation typically corresponds to open file descriptors at the fd.c level, leaving it open when there's no corresponding relcache entry can mean that we prevent the kernel from reclaiming deleted disk space. (While CacheInvalidateSmgr messages usually fix that, there are cases where they're not issued, such as DROP DATABASE. We might want to add some more sinval messaging for that, but I'd be inclined to keep this type of logic anyway, since allowing VFDs to accumulate indefinitely for blind-written relations doesn't seem like a good idea.) This code replaces a previous attempt towards the same goal that proved to be unreliable. Back-patch to 9.1 where the previous patch was added. http://git.postgresql.org/pg/commitdiff/ff3f9c8de5846be7709b7a87654631b4c309a68b
  • Revert "Use "transient" files for blind writes, take 2". This reverts commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c. That approach had problems with the smgr-level state not tracking what we really want to happen, and with the VFD-level state not tracking the smgr-level state very well either. In consequence, it was still possible to hold kernel file descriptors open for long-gone tables (as in recent report from Tore Halset), and yet there were also cases of FDs being closed undesirably soon. A replacement implementation will follow. http://git.postgresql.org/pg/commitdiff/9bacf0e3734f0b5dc821abf7cb312377876e22d3
  • Fix planning of non-strict equivalence clauses above outer joins. If a potential equivalence clause references a variable from the nullable side of an outer join, the planner needs to take care that derived clauses are not pushed to below the outer join; else they may use the wrong value for the variable. (The problem arises only with non-strict clauses, since if an upper clause can be proven strict then the outer join will get simplified to a plain join.) The planner attempted to prevent this type of error by checking that potential equivalence clauses aren't outerjoin-delayed as a whole, but actually we have to check each side separately, since the two sides of the clause will get moved around separately if it's treated as an equivalence. Bugs of this type can be demonstrated as far back as 7.4, even though releases before 8.3 had only a very ad-hoc notion of equivalence clauses. In addition, we neglected to account for the possibility that such clauses might have nonempty nullable_relids even when not outerjoin-delayed; so the equivalence-class machinery lacked logic to compute correct nullable_relids values for clauses it constructs. This oversight was harmless before 9.2 because we were only using RestrictInfo.nullable_relids for OR clauses; but as of 9.2 it could result in pushing constructed equivalence clauses to incorrect places. (This accounts for bug #7604 from Bill MacArthur.) Fix the first problem by adding a new test check_equivalence_delay() in distribute_qual_to_rels, and fix the second one by adding code in equivclass.c and called functions to set correct nullable_relids for generated clauses. Although I believe the second part of this is not currently necessary before 9.2, I chose to back-patch it anyway, partly to keep the logic similar across branches and partly because it seems possible we might find other reasons why we need valid values of nullable_relids in the older branches. Add regression tests illustrating these problems. In 9.0 and up, also add test cases checking that we can push constants through outer joins, since we've broken that optimization before and I nearly broke it again with an overly simplistic patch for this problem. http://git.postgresql.org/pg/commitdiff/72a4231f0c80f213a4fa75356dc3c6b7c7419059
  • Code review for inline-list patch. Make foreach macros less syntactically dangerous, and fix some typos in evidently-never-tested ones. Add missing slist_next_node and slist_head_node functions. Fix broken dlist_check code. Assorted comment improvements. http://git.postgresql.org/pg/commitdiff/8f8d74647880ef53fc674498827b8b8e6c80d125
  • Remove unnecessary "head" arguments from some dlist/slist functions. dlist_delete, dlist_insert_after, dlist_insert_before, slist_insert_after do not need access to the list header, and indeed insisting on that negates one of the main advantages of a doubly-linked list. In consequence, revert addition of "cache_bucket" field to CatCTup. http://git.postgresql.org/pg/commitdiff/dc5aeca168629183e64087b1147d3c2645e49ddc
  • Further cleanup of catcache.c ilist changes. Remove useless duplicate initialization of bucket headers, don't use a dlist_mutable_iter in a performance-critical path that doesn't need it, make some other cosmetic changes for consistency's sake. http://git.postgresql.org/pg/commitdiff/002191a1a39c8dba8d0331c123a6c82724af6d87
  • Provide some static-assertion functionality on all compilers. On reflection (especially after noticing how many buildfarm critters have __builtin_types_compatible_p but not _Static_assert), it seems like we ought to try a bit harder to make these macros do something everywhere. The initial cut at it would have been no help to code that is compiled only on platforms without _Static_assert, for instance; and in any case not all our contributors do their initial coding on the latest gcc version. Some googling about static assertions turns up quite a bit of prior art for making it work in compilers that lack _Static_assert. The method that seems closest to our needs involves defining a struct with a bit-field that has negative width if the assertion condition fails. There seems no reliable way to get the error message string to be output, but throwing a compile error with a confusing message is better than missing the problem altogether. In the same spirit, if we don't have __builtin_types_compatible_p we can at least insist that the variable have the same width as the type. This won't catch errors such as "wrong pointer type", but it's far better than nothing. In addition to changing the macro definitions, adjust a compile-time-constant Assert in contrib/hstore to use StaticAssertStmt, so we can get some buildfarm coverage on whether that macro behaves sanely or not. There's surely more places that could be converted, but this is the first one I came across. http://git.postgresql.org/pg/commitdiff/0d0aa5d29175c539db1981be27dbbf059be6f3b1
  • Fix ruleutils to print "INSERT INTO foo DEFAULT VALUES" correctly. Per bug #7615 from Marko Tiikkaja. Apparently nobody ever tried this case before ... http://git.postgresql.org/pg/commitdiff/0d6895051a2e53026ad0daae0ebc3cb901acc521
  • Fix hash_search to avoid corruption of the hash table on out-of-memory. An out-of-memory error during expand_table() on a palloc-based hash table would leave a partially-initialized entry in the table. This would not be harmful for transient hash tables, since they'd get thrown away anyway at transaction abort. But for long-lived hash tables, such as the relcache hash, this would effectively corrupt the table, leading to crash or other misbehavior later. To fix, rearrange the order of operations so that table enlargement is attempted before we insert a new entry, rather than after adding it to the hash table. Problem discovered by Hitoshi Harada, though this is a bit different from his proposed patch. http://git.postgresql.org/pg/commitdiff/4e32f8cd14fa6c66400e8af188bea78b22cf5f56
  • Fix UtilityContainsQuery() to handle CREATE TABLE Alexander Shulgin EXECUTE correctly. The code seems to have been written to handle the pre-parse-analysis representation, where an ExecuteStmt would appear directly under CreateTableAsStmt. But in reality the function is only run on already-parse-analyzed statements, so there will be a Query node in between. We'd not noticed the bug because the function is generally not used at all except in extended query protocol. Per report from Robert Haas and Rushabh Lathia. http://git.postgresql.org/pg/commitdiff/5d1abe64e62f2bb3c1a8a4181974f0b17b8bc21d
  • Prevent overflow in pgbench's percent-done display. Per Thom Brown. http://git.postgresql.org/pg/commitdiff/ca0b960eb502db429d9134b0ddf24b9e12f45257
  • Fix pg_dump's handling of DROP DATABASE commands in --clean mode. In commit 4317e0246c645f60c39e6572644cff1cb03b4c65, I accidentally broke this behavior while rearranging code to ensure that --create wouldn't affect whether a DATABASE entry gets put into archive-format output. Thus, 9.2 would issue a DROP DATABASE command in --clean mode, which is either useless or dangerous depending on the usage scenario. It should not do that, and no longer does. A bright spot is that this refactoring makes it easy to allow the combination of --clean and --create to work sensibly, ie, emit DROP DATABASE then CREATE DATABASE before reconnecting. Ordinarily we'd consider that a feature addition and not back-patch it, but it seems silly to not include the extra couple of lines required in the 9.2 version of the code. Per report from Guillaume Lelarge, though this is slightly more extensive than his proposed patch. http://git.postgresql.org/pg/commitdiff/edef20f6e1e7a02c65163f1054ce71db4d719aad

Bruce Momjian a poussé :

Simon Riggs a poussé :

Alvaro Herrera a poussé :

  • Embedded list interface. Provide a common implementation of embedded singly-linked and doubly-linked lists. "Embedded" in the sense that the nodes' next/previous pointers exist within some larger struct; this design choice reduces memory allocation overhead. Most of the implementation uses inlineable functions (where supported), for performance. Some existing uses of both types of lists have been converted to the new code, for demonstration purposes. Other uses can (and probably will) be converted in the future. Since dllist.c is unused after this conversion, it has been removed. Author: Andres Freund Some tweaks by me Reviewed by Tom Lane, Peter Geoghegan http://git.postgresql.org/pg/commitdiff/a66ee69add6e129c7674a59f8c3ba010ed4c9386
  • pg_dump: Output functions deterministically sorted. Implementation idea from Tom Lane Author: Joel Jacobson Reviewed by Joachim Wieland http://git.postgresql.org/pg/commitdiff/7b583b20b1c95acb621c71251150beef958bb603

Andrew Dunstan a poussé :

Correctifs rejetés (à ce jour)

  • Jeremy Evans patch to always include encoding of database in pg_dumpall.

Correctifs en attente

  • Zoltan Boszormenyi sent in another revision of the patch to allow pg_basebackup to configure and start standby.
  • Andrew Dunstan sent in another revision of the patch to add parallel pg_dump.
  • Pavel Stehule and Shigeru HANADA traded patches to implement \gset in psql.
  • Amit Kapila sent in another revision of the patch to truncate trailing nulls from heap rows to reduce the size of the null bitmap.
  • KaiGai Kohei sent in another revision of the patch implementing row-level access control.
  • Amit Kapila sent in another revision of the patch to reduce the amount of WAL used in update operations.
  • Karl O. Pinc sent in a patch to add --truncate-tables to pg_restore.
  • Karl O. Pinc sent in a doc patch to fix an punctuation error for pg_restore.
  • Karl O. Pinc sent in a word-smithing doc patch for pg_restore.
  • Peter Geoghegan sent in another revision of the patch to use grow_memtuples with sort_mem.
  • Shigeru HANADA sent in another revision of the patch to make dropping multiple tables in a single transaction faster.
  • Kevin Grittner sent in three revisions of a patch to fix CREATE/DROP INDEX CONCURRENTLY.
  • Claudio Freire sent in two revisions of a patch to prefetch index pages for B-Tree index scans.
  • Kyotaro HORIGUCHI sent in three revisions of a patch to fix an issue in pg_stat_replication where sync_state is not being properly set.
  • Alvaro Herrera sent in another revision of the patch implementing foreign key locks.
  • Will Leinweber sent in a patch to add \watch to psql.
  • Tom Lane sent in a bug to fix the -c option in pg_dump/pg_restore.