Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en février

PostgreSQL Local

  • Le PGDay NYC aura lieu le 2 avril 2012 au Lighthouse International à New-York : http://pgday.nycpug.org
  • La PGCon 2012 sera tenue à l'Université d'Ottawa, les 17 et 18 mai 2012. Elle sera précédée par deux jours de tutoriels les 15 & 16 mai 2012 : http://www.pgcon.org/2012/
  • Le PGDay France aura lieu à Lyon, le 7 juin 2012 : http://www.pgday.fr

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)

Revues de code

Correctifs appliqués

Heikki Linnakangas a poussé :

Andrew Dunstan a poussé :

Michael Meskes a poussé :

Bruce Momjian a poussé :

Robert Haas a poussé :

Tom Lane a poussé :

  • Preserve column names in the execution-time tupledesc for a RowExpr. The hstore and json datatypes both have record-conversion functions that pay attention to column names in the composite values they're handed. We used to not worry about inserting correct field names into tuple descriptors generated at runtime, but given these examples it seems useful to do so. Observe the nicer-looking results in the regression tests whose results changed. catversion bump because there is a subtle change in requirements for stored rule parsetrees: RowExprs from ROW() constructs now have to include field names. Andrew Dunstan and Tom Lane http://git.postgresql.org/pg/commitdiff/398f70ec070fe60151584eaa448f04708aa77892
  • Run a portal's cleanup hook immediately when pushing it to FAILED state. This extends the changes of commit 6252c4f9e201f619e5eebda12fa867acd4e4200e so that we run the cleanup hook earlier for failure cases as well as success cases. As before, the point is to avoid an assertion failure from an Assert I added in commit a874fe7b4c890d1fe3455215a83ca777867beadd, which was meant to check that no user-written code can be called during portal cleanup. This fixes a case reported by Pavan Deolasee in which the Assert could be triggered during backend exit (see the new regression test case), and also prevents the possibility that the cleanup hook is run after portions of the portal's state have already been recycled. That doesn't really matter in current usage, but it foreseeably could matter in the future. Back-patch to 9.1 where the Assert in question was added. http://git.postgresql.org/pg/commitdiff/4bfe68dfab009ce8fcaea79dc0832eadf3380051
  • Improve statistics estimation to make some use of DISTINCT in sub-queries. Formerly, we just punted when trying to estimate stats for variables coming out of sub-queries using DISTINCT, on the grounds that whatever stats we might have for underlying table columns would be inapplicable. But if the sub-query has only one DISTINCT column, we can consider its output variable as being unique, which is useful information all by itself. The scope of this improvement is pretty narrow, but it costs nearly nothing, so we might as well do it. Per discussion with Andres Freund. This patch differs from the draft I submitted yesterday in updating various comments about vardata.isunique (to reflect its extended meaning) and in tweaking the interaction with security_barrier views. There does not seem to be a reason why we can't use this sort of knowledge even when the sub-query is such a view. http://git.postgresql.org/pg/commitdiff/4767bc8ff2edc1258cf4d8a83155d4cedd724231
  • Fix longstanding error in contrib/intarray's int[] & int[] operator. The array intersection code would give wrong results if the first entry of the correct output array would be "1". (I think only this value could be at risk, since the previous word would always be a lower-bound entry with that fixed value.) Problem spotted by Julien Rouhaud, initial patch by Guillaume Lelarge, cosmetic improvements by me. http://git.postgresql.org/pg/commitdiff/06d9afa6f93ec08a45da4de7afd97bbf16738739
  • Sync regex code with Tcl 8.5.11. Sync our regex code with upstream changes since last time we did this, which was Tcl 8.5.0 (see commit df1e965e12cdd48c11057ee6e15346ee2b8b02f5). There are no functional changes here; the main point is just to lay down a commit-log marker that somebody has looked at this recently, and to do what we can to keep the two codebases comparable. http://git.postgresql.org/pg/commitdiff/08fd6ff37f71485e2fc04bc6ce07d2a483c36702
  • Update expected/collate.linux.utf8.out for recent plpgsql changes. This file was missed in commit 4c6cedd1b014abf2046886a9a92e10e18f0d658e. http://git.postgresql.org/pg/commitdiff/759c95c45b65a5220976c85e6f03323975c2b276
  • Create the beginnings of internals documentation for the regex code. Create src/backend/regex/README to hold an implementation overview of the regex package, and fill it in with some preliminary notes about the code's DFA/NFA processing and colormap management. Much more to do there of course. Also, improve some code comments around the colormap and cvec code. No functional changes except to add one missing assert. http://git.postgresql.org/pg/commitdiff/27af91438b68f46f4015853b6f75c6f5c3a8650c
  • Add caching of ctype.h/wctype.h results in regc_locale.c. While this doesn't save a huge amount of runtime, it still seems worth doing, especially since I realized that the data copying I did in my first draft was quite unnecessary. In this version, once we have the results cached, getting them back for re-use is really very cheap. Also, remove the hard-wired limitation to not consider wctype.h results for character codes above 255. It turns out that we can't push the limit as far up as I'd originally hoped, because the regex colormap code is not efficient enough to cope very well with character classes containing many thousand letters, which a Unicode locale is entirely capable of producing. Still, we can push it up to U+7FF (which I chose as the limit of 2-byte UTF8 characters), which will at least make Eastern Europeans happy pending a better solution. Thus, this commit resolves the specific complaint in bug #6457, but not the more general issue that letters of non-western alphabets are mostly not recognized as matching [[:alpha:]]. http://git.postgresql.org/pg/commitdiff/e00f68e49c148851187136d3278b7e9afa370537
  • Fix regex back-references that are directly quantified with *. The syntax "\n*", that is a backref with a * quantifier directly applied to it, has never worked correctly in Spencer's library. This has been an open bug in the Tcl bug tracker since 2005: https://sourceforge.net/tracker/index.php?func=detail&aid=1115587&group_id=10894&atid=110894 The core of the problem is in parseqatom(), which first changes "\n*" to "\n+|" and then applies repeat() to the NFA representing the backref atom. repeat() thinks that any arc leading into its "rp" argument is part of the sub-NFA to be repeated. Unfortunately, since parseqatom() already created the arc that was intended to represent the empty bypass around "\n+", this arc gets moved too, so that it now leads into the state loop created by repeat(). Thus, what was supposed to be an "empty" bypass gets turned into something that represents zero or more repetitions of the NFA representing the backref atom. In the original example, in place of ^([bc])\1*$ we now have something that acts like ^([bc])(\1+|[bc]*)$ At runtime, the branch involving the actual backref fails, as it's supposed to, but then the other branch succeeds anyway. We could no doubt fix this by some rearrangement of the operations in parseqatom(), but that code is plenty ugly already, and what's more the whole business of converting "x*" to "x+|" probably needs to go away to fix another problem I'll mention in a moment. Instead, this patch suppresses the *-conversion when the target is a simple backref atom, leaving the case of m == 0 to be handled at runtime. This makes the patch in regcomp.c a one-liner, at the cost of having to tweak cbrdissect() a little. In the event I went a bit further than that and rewrote cbrdissect() to check all the string-length-related conditions before it starts comparing characters. It seems a bit stupid to possibly iterate through many copies of an n-character backreference, only to fail at the end because the target string's length isn't a multiple of n --- we could have found that out before starting. The existing coding could only be a win if integer division is hugely expensive compared to character comparison, but I don't know of any modern machine where that might be true. This does not fix all the problems with quantified back-references. In particular, the code is still broken for back-references that appear within a larger expression that is quantified (so that direct insertion of the quantification limits into the BACKREF node doesn't apply). I think fixing that will take some major surgery on the NFA code, specifically introducing an explicit iteration node type instead of trying to transform iteration into concatenation of modified regexps. Back-patch to all supported branches. In HEAD, also add a regression test case for this. (It may seem a bit silly to create a regression test file for just one test case; but I'm expecting that we will soon import a whole bunch of regex regression tests from Tcl, so might as well create the infrastructure now.) http://git.postgresql.org/pg/commitdiff/5223f96d92fd6fb6fcf260da9f9cb111831f0b37

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Marko Kreen and Kyotaro HORIGUCHI traded patches to create, and use in dblink, a new tuple storage for libpq.
  • Etsuro Fujita and Shigeru HANADA traded patches to make a PostgreSQL FDW.
  • Alvaro Herrera sent in another revision of the patch to create a special lock type for foreign keys.
  • Heikki Linnakangas sent in two more revisions of a patch to scale xlog insertion.
  • Dimitri Fontaine sent in a patch to fix an issue with DROP EXTENSION.
  • Chetan Suttraway sent in another revision of the patch to optimize referential integrity checks.
  • Jaime Casanova sent in a flock of patches which: adds gin and spgist support to pgstattuple and makes pgstattuple use a ring buffer when reading tables or indexes, adds the relation_free_space function to pgstattuple, and adds a stats_target parameter to the relation_free_space() function.
  • Dimitri Fontaine sent in four more revisions of the patch to add command triggers.
  • Alexander Korotkov sent in two more revision of the patch to make some speed improvements on inserting and indexing cubes.
  • Dan Ports sent in a patch to fix a possible incompatibility between prepared transactions and SSI.
  • Peter Eisentraut sent in another revision of the patch to control the location of server-side SSL files via a new GUC.
  • MauMau sent in a patch to fix a bug in windows debug builds where the postmaster would always crash.
  • Simon Riggs sent in three more revisions of the patch to add page checksums.
  • Kevin Grittner sent in another revision of the patch to (re-)run GUC check hooks on RESET.
  • Dan Scales sent in a patch implementing a new option for wal_sync_method intended to improve performance.
  • Peter Geoghegan sent in another revision of the patch to normalize pg_stat_statements.
  • Robert Haas sent in another revision of the patch to display autovacuum accumulated cost.
  • Robert Haas sent in another revision of the patch to simulate clog contention.
  • Peter Eisentraut sent in a patch to make pg_regress set the application name rather than leaving it as psql.
  • Jan Urbanski sent in a patch to add PL/Python execution contexts.
  • Jan Urbanski sent in a patch to fix some reference miscounts and segfaults in PL/Python.
  • Simon Riggs sent in a patch intended to reduce the frequency of bgwriter wakeups.
  • Pavel Stehule sent in a patch to add tab completion for functions to psql.
  • Pavel Stehule sent in a patch to add tab completion for CREATE OR REPLACE FUNCTION in psql.