Philly PUG [ndt: PUG de Philadelphie] tiendra sa première réunion le 12 septembre 2012. Bruce Momjian y présentera : «Quoi de neuf dans PostgreSQL 9.2». Détails et RSVP ci-après : http://www.phlpug.org/events/78529522/

PgDay Argentina 2012, une mini-conférence mettant en relation entreprises et nouveaux utilisateurs avec la communauté PostgreSQL, aura lieu le 13 novembre 2012 à Buenos Aires, Argentine : http://www.pgday.com.ar/buenosaires2012

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.

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 anglaises sur le processus de candidature disponibles ci-après : http://2012.pgday.it/call-for-papers/international-call-for-papers/

PostgreSQL Local

  • La 4ème Session PostgreSQL aura lieu le 4 octobre 2012 à Paris. Plus d'informations sur : http://www.postgresql-sessions.org/en/4/
  • La PostgreSQL Conference Europe 2012 aura lieu à Prague, République Tchèque, du 23 au 26 octobre. L'appel à conférenciers est lancé : http://2012.pgconf.eu/
  • 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

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é :

Bruce Momjian a poussé :

Tom Lane a poussé :

  • Fix DROP INDEX CONCURRENTLY IF EXISTS. This threw ERROR, not the expected NOTICE, if the index didn't exist. The bug was actually visible in not-as-expected regression test output, so somebody wasn't paying too close attention in commit 8cb53654dbdb4c386369eb988062d0bbb6de725e. Per report from Brendan Byrd. http://git.postgresql.org/pg/commitdiff/e323c553017601597b6a5f9f19426587df512ad9
  • Add section IDs to subsections of syntax.sgml that lacked them. This is so that these sections will have stable HTML tags that one can link to, rather than things like "AEN1902". Perhaps we should mount a campaign to do this everywhere, but I've found myself pointing at syntax.sgml subsections often enough to be sure it's useful here. http://git.postgresql.org/pg/commitdiff/87703287849bf785400d0daf57b9d6b5a05d0780
  • Improve a couple of 9.2 release note entries. Clarify the compatibility notes about EXTRACT() and about statistics timing columns. http://git.postgresql.org/pg/commitdiff/7417a8e3dd14886887447053a5ccbd4f9501ba61
  • Remove hstore--1.0.sql. Since we're not installing this file anymore, it has no reason to exist, other than as historical reference; but we have an SCM for that. http://git.postgresql.org/pg/commitdiff/9db098dfa91906cee4fffc1e3ba8ba3899820d5f
  • Remove pg_stat_statements--1.0.sql, too. Per Peter Geoghegan. http://git.postgresql.org/pg/commitdiff/0a83f2492f38fd0b82452dfd2a80cc70486ba73d
  • Adjust definition of cheapest_total_path to work better with LATERAL. In the initial cut at LATERAL, I kept the rule that cheapest_total_path was always unparameterized, which meant it had to be NULL if the relation has no unparameterized paths. It turns out to work much more nicely if we always have *some* path nominated as cheapest-total for each relation. In particular, let's still say it's the cheapest unparameterized path if there is one; if not, take the cheapest-total-cost path among those of the minimum available parameterization. (The first rule is actually a special case of the second.) This allows reversion of some temporary lobotomizations I'd put in place. In particular, the planner can now consider hash and merge joins for joins below a parameter-supplying nestloop, even if there aren't any unparameterized paths available. This should bring planning of LATERAL-containing queries to the same level as queries not using that feature. Along the way, simplify management of parameterized paths in add_path() and friends. In the original coding for parameterized paths in 9.2, I tried to minimize the logic changes in add_path(), so it just treated parameterization as yet another dimension of comparison for paths. We later made it ignore pathkeys (sort ordering) of parameterized paths, on the grounds that ordering isn't a useful property for the path on the inside of a nestloop, so we might as well get rid of useless parameterized paths as quickly as possible. But we didn't take that reasoning as far as we should have. Startup cost isn't a useful property inside a nestloop either, so add_path() ought to discount startup cost of parameterized paths as well. Having done that, the secondary sorting I'd implemented (in add_parameterized_path) is no longer needed --- any parameterized path that survives add_path() at all is worth considering at higher levels. So this should be a bit faster as well as simpler. http://git.postgresql.org/pg/commitdiff/e83bb10d6dcf05a666d4ada00d9788c7974ad378
  • Improve EXPLAIN's ability to cope with LATERAL references in plans. push_child_plan/pop_child_plan didn't bother to adjust the "ancestors" list of parent plan nodes when descending to a child plan node. I think this was okay when it was written, but it's not okay in the presence of LATERAL references, since a subplan node could easily be returning a LATERAL value back up to the same nestloop node that provides the value. Per changed regression test results, the omission led to failure to interpret Param nodes that have perfectly good interpretations. http://git.postgresql.org/pg/commitdiff/d1a4db8d25ec53fd17e99168bc5efa0b16ef6fed
  • Suppress creation of backwardly-indexed paths for LATERAL join clauses. Given a query such as SELECT * FROM foo JOIN LATERAL (SELECT foo.var1) ss(x) ON ss.x = foo.var2 the existence of the join clause "ss.x = foo.var2" encourages indxpath.c to build a parameterized path for foo using any index available for foo.var2. This is completely useless activity, though, since foo has got to be on the outside not the inside of any nestloop join with ss. It's reasonably inexpensive to add tests that prevent creation of such paths, so let's do that. http://git.postgresql.org/pg/commitdiff/77387f0ac859c099c6ab669db1e7a852524696c4
  • Improve coding of gistchoose and gistRelocateBuildBuffersOnSplit. This is mostly cosmetic, but it does eliminate a speculative portability issue. The previous coding ignored the fact that sum_grow could easily overflow (in fact, it could be summing multiple IEEE float infinities). On a platform where that didn't guarantee to produce a positive result, the code would misbehave. In any case, it was less than readable. http://git.postgresql.org/pg/commitdiff/e5db11c5582b469c04a11f217a0f32c827da5dd7
  • Make configure probe for mbstowcs_l as well as wcstombs_l. We previously supposed that any given platform would supply both or neither of these functions, so that one configure test would be sufficient. It now appears that at least on AIX this is not the case ... which is likely an AIX bug, but nonetheless we need to cope with it. So use separate tests. Per bug #6758; thanks to Andrew Hastie for doing the followup testing needed to confirm what was happening. Backpatch to 9.1, where we began using these functions. http://git.postgresql.org/pg/commitdiff/58a031f920c225b20fdb45c1e56fe41ed7568900
  • Fix LATERAL references to join alias variables. I had thought this case worked already, but perhaps I didn't re-test it after adding extract_lateral_references() ... http://git.postgresql.org/pg/commitdiff/da3df998702061b4b63d83d5354b148e812f21f8
  • Partially restore qual scope checks in distribute_qual_to_rels(). The LATERAL implementation is now basically complete, and I still don't see a cost-effective way to make an exact qual scope cross-check in the presence of LATERAL. However, I did add a PlannerInfo.hasLateralRTEs flag along the way, so it's easy to make the check only when not hasLateralRTEs. That seems to still be useful, and it beats having no check at all. http://git.postgresql.org/pg/commitdiff/c97a547a4a0913e37e5dd1f026ac3c281326b215
  • More documentation updates for LATERAL. Extend xfunc.sgml's discussion of set-returning functions to show an example of using LATERAL, and recommend that over putting SRFs in the targetlist. In passing, reword func.sgml's section on set-returning functions so that it doesn't claim that the functions listed therein are all the built-in set-returning functions. That hasn't been true for a long time, and trying to make it so doesn't seem like it would be an improvement. (Perhaps we should rename that section?) Both per suggestions from Merlin Moncure. http://git.postgresql.org/pg/commitdiff/06310178ef54720bc4ed7bc85c887e6ebed24d83
  • Fix broken link in installation.sgml. Linking to other parts of the manual doesn't work when building the standalone INSTALL document. http://git.postgresql.org/pg/commitdiff/b8a4093b5890aa774ae90bbf44515750aa0ae85c
  • Fix mark_placeholder_maybe_needed to handle LATERAL references. If a PlaceHolderVar contains a pulled-up LATERAL reference, its minimum possible evaluation level might be higher in the join tree than its original syntactic location. That in turn affects the ph_needed level for any contained PlaceHolderVars (that is, those PHVs had better propagate up the join tree at least to the evaluation level of the outer PHV). We got this mostly right, but mark_placeholder_maybe_needed() failed to account for the effect, and in consequence could leave the inner PHVs with ph_may_need less than what their ultimate ph_needed value will be. That's bad because it could lead to failure to select a join order that will allow evaluation of the inner PHV at a valid location. Fix that, and add an Assert that checks that we don't ever set ph_needed to more than ph_may_need. http://git.postgresql.org/pg/commitdiff/4da6439bd8553059766011e2a42c6e39df08717f
  • Drop cheap-startup-cost paths during add_path() if we don't need them. We can detect whether the planner top level is going to care at all about cheap startup cost (it will only do so if query_planner's tuple_fraction argument is greater than zero). If it isn't, we might as well discard paths immediately whose only advantage over others is cheap startup cost. This turns out to get rid of quite a lot of paths in complex queries --- I saw planner runtime reduction of more than a third on one large query. Since add_path isn't currently passed the PlannerInfo "root", the easiest way to tell it whether to do this was to add a bool flag to RelOptInfo. That's a bit redundant, since all relations in a given query level will have the same setting. But in the future it's possible that we'd refine the control decision to work on a per-relation basis, so this seems like a good arrangement anyway. Per my suggestion of a few months ago. http://git.postgresql.org/pg/commitdiff/6d2c8c0e2afa8cbaf99555a24336e93118fd181e

Alvaro Herrera a poussé :

Robert Haas a poussé :

Peter Eisentraut a poussé :

Andrew Dunstan a poussé :

  • Restore setting of _USE_32BIT_TIME_T to 32 bit MSVC builds. This was removed in commit cd004067742ee16ee63e55abfb4acbd5f09fbaab, we're not quite sure why, but there have been reports of crashes due to Alexander Shulgin Perl being built with it when we are not, and it certainly seems like the right thing to do. There is still some uncertainty as to why it sometimes fails and sometimes doesn't. Original patch from Owais Khani, substantially reworked and extended by Andrew Dunstan. http://git.postgresql.org/pg/commitdiff/ef58b87df2afe91189e9ffb81b65c1127d53bc88

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Dickson S. Guedes sent in another revision of the patch to add IF NOT EXISTS to CREATE SCHEMA.
  • Amit Kapila sent in another revision of the patch to improve performance by reducing WAL for update operations.
  • Alvaro Herrera sent in two more revisions of the patch to add foreign key locks.
  • Dimitri Fontaine sent in a patch tweaking the behavior of EVENT triggers.
  • Dean Rasheed sent in three more revisions of the patch to implement updatable views.
  • Tom Lane sent in a patch to fix an issue where function parameters aren't getting to the functions they are part of because of the lack of type inference.
  • Amit Kapila sent in a patch to document pg_resetxlog and compute the max LSN of data pages.
  • Owais Khan and Andrew Dunstan traded patches to use a 32-bit time_t structure on Windows in order not to break PL/Perl.
  • Dimitri Fontaine sent in a patch to prevent event triggers from firing in stand-alone mode.
  • Peter Eisentraut sent in a patch to change the many "%d tuples done" lines to a sort of progress counter that stays on the same line.
  • Pavel Stehule sent in another revision of the patch to allow tuning the display of booleans in psql.
  • Bruce Momjian and Tom Lane traded patches to make a pg_upgrade failure mode involving socket directories less likely.
  • KaiGai Kohei sent in a patch to fix a case sepgsql missed in CREATE TABLE AS.
  • KaiGai Kohei sent in a patch to make sepgsql follow recent changes to the core API.
  • Tomas Vondra sent in two more revisions of the patch to enable pgbench to write random samples into the transaction log.
  • Andrew Dunstan sent in a patch to make pg_upgrade work on Windows.
  • Andrew Dunstan sent in a patch to make pg_upgrade's "make check" work on Windows with Mingw.
  • Tom Lane sent in a proof-of-concept patch for talking to a standalone backend using libpq and a pair of pipes.