PostgreSQL La base de donnees la plus sophistiquee au monde.

La planète francophone de PostgreSQL

mercredi 22 mai 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 19 mai 2013

Si vous assistez à la PGCon cette année, n'hésitez pas à soumettre une proposition pour un lightning talk : http://lists.pgcon.org/pipermail/pgcon-announce/2013-May/000100.html

PGDay UK 2013 est à présent ouvert aux inscriptions : http://postgresqlusergroup.org.uk

L'appel à conférenciers pour le pgconf.eu 2013 est lancé : http://2013.pgconf.eu/

Offres d'emplois autour de PostgreSQL en mai

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

Tom Lane a poussé :

  • Fix handling of OID wraparound while in standalone mode. If OID wraparound should occur while in standalone mode (unlikely but possible), we want to advance the counter to FirstNormalObjectId not FirstBootstrapObjectId. Otherwise, user objects might be created with OIDs in the system-reserved range. That isn't immediately harmful but it poses a risk of conflicts during future pg_upgrade operations. Noted by Andres Freund. Back-patch to all supported branches, since all of them are supported sources for pg_upgrade operations. http://git.postgresql.org/pg/commitdiff/e9c336c78638c191642b18628c306d1c1573fb12
  • Allow CREATE FOREIGN TABLE to include SERIAL columns. The behavior is that the required sequence is created locally, which is appropriate because the default expression will be evaluated locally. Per gripe from Brad Nicholson that this case was refused with a confusing error message. We could have improved the error message but it seems better to just allow the case. Also, remove ALTER TABLE's arbitrary prohibition against being applied to foreign tables, which was pretty inconsistent considering we allow it for views, sequences, and other relation types that aren't even called tables. This is needed to avoid breaking pg_dump, which sometimes emits column defaults using separate ALTER TABLE commands. (I think this can happen even when the default is not associated with a sequence, so that was a pre-existing bug once we allowed column defaults for foreign tables.) http://git.postgresql.org/pg/commitdiff/b14206862278347a379f2bb72d92d16fb9dcea45
  • Fix some uses of "the quick brown fox". If we're going to quote a well-known pangram, we should quote it accurately. Per gripe from Thom Brown. http://git.postgresql.org/pg/commitdiff/e7bfc7e42cebf80507f9c9965dc4a572e9fb76a4
  • Fix fd.c to preserve errno where needed. PathNameOpenFile failed to ensure that the correct value of errno was returned to its caller after a failure (because it incorrectly supposed that free() can never change errno). In some cases this would result in a user-visible failure because an expected ENOENT errno was replaced with something else. Bogus EINVAL failures have been observed on OS X, for example. There were also a couple of places that could mangle an important value of errno if FDDEBUG was defined. While the usefulness of that debug support is highly debatable, we might as well make it safe to use, so add errno save/restore logic to the DO_DB macro. Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/6563fb2b45146852601e63828308fe04fb03b9e9
  • Fix crash when trying to display a NOTIFY rule action. Fixes oversight in commit 2ffa740be9d96a3743ecb7e42391c53d0760c65a. Per report from Josh Kupershmidt. I think we've broken this case before, so let's add a regression test this time. http://git.postgresql.org/pg/commitdiff/403bd6a18b8ec5aeee51c08360441c3c3c239d8f
  • Clarify documentation of EXPLAIN (TIMING OFF) option. Clarify that this option doesn't suppress measurement of the statement's total runtime. Greg Smith http://git.postgresql.org/pg/commitdiff/2af0971f35a4a7b87312b83782d9bb0cc6a40ad0

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

Simon Riggs a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Noah Misch sent in a patch to implement MemoryContextAllocHuge() and repalloc_huge()
  • Peter Geoghegan sent in a patch to ensure that all "loaded library..." messages are DEBUG1, regardless of whether local_preload_libraries or shared_preload_libraries is involved, and regardless of EXEC_BACKEND.
  • Robins Tharakan sent in a patch to add more tests for ASYNC.
  • Heikki Linnakangas sent in a patch to improve LWLocks by using compare-and-swap CPU instructions where available.
  • Peter Eisentraut sent in a patch to make psql delay setting up its cancel handler until after a database connection is established.
  • Mark Kirkwood sent in a patch to add pg_stat_get_changes_since_analyze() and associated columns to system views.
  • Amit Kapila sent in two revisions of a patch to move unused buffers to freelist.
  • Maciej Gajewski sent in a patch to cache and query result histories in psql.
  • Peter Geoghegan sent in another revision of a patch to replace our quicksort_arg with timsort_arg.
  • Amit Langote sent four patches intended to allow logging PAM auth failure.
  • Jon Nelson sent in three more revisions of a patch to use fallocate where available, reducing the time it takes to write a WAL file.
  • Dean Rasheed sent in a patch to ensure that views atop writeable foreign tables are writeable along with changes to catalog views showing foreign tables' writeability.
  • Amul Sul sent in a patch to add a connection request wait time to psql.
  • Cedric Villemain sent in a WIP patch to fix a case where 9.3 breaks extensions.
  • Heikki Linnakangas sent in a patch to fix a quoting issue in pg_basebackup.
  • Joe Abbate sent in a patch to fix an issue in the release notes about DROP TABLE ... IF EXISTS.
  • Dan Farina sent in a set of patches to enrich the auth mechanism in libpq.
  • Greg Smith sent in a WIP patch to track block write statistics.
  • Chris Farmiloe sent in a patch to hook the privilege system to LISTEN/NOTIFY.

par N Bougain le mercredi 22 mai 2013 à 22h50

lundi 20 mai 2013

Guillaume Lelarge

Traduction de la documentation de PostgreSQL 9.3

Contrairement à l'année dernière, le merge a été beaucoup plus rapide. En moins de trois jours, il était terminé. Il est donc possible de commencer la traduction.

Ceux qui veulent participer sont les bienvenus. La liste des fichiers et les instructions sont disponibles sur : https://github.com/gleu/pgdocs_fr/wiki/translation-9.3. Il est possible que j'ai besoin de donner le droit de modifier cette page, on verra bien. J'avoue que je ne connais pas bien le système wiki de github.

De mon côté, je vais commencer certainement dès demain.

Pour ceux qui ont besoin de cette documentation, elle est disponible sur http://docs.postgresql.fr/9.3/. Elle sera mise à jour au fur et à mesure de l'avancement de la traduction (donc, là, c'est juste la documentation de la 9.2 en français, dans laquelle se trouvent greffés les ajouts de la 9.3 en anglais).

par Guillaume Lelarge le lundi 20 mai 2013 à 17h01

mercredi 15 mai 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 12 mai 2013

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en mai

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

Bruce Momjian a poussé :

Simon Riggs a poussé :

Tom Lane a poussé :

  • Disallow unlogged materialized views. The initial implementation of this feature was really unsupportable, because it's relying on the physical size of an on-disk file to carry the relation's populated/unpopulated state, which is at least a modularity violation and could have serious long-term consequences. We could say that an unlogged matview goes to empty on crash, but not everybody likes that definition, so let's just remove the feature for 9.3. We can add it back when we have a less klugy implementation. I left the grammar and tab-completion support for CREATE UNLOGGED MATERIALIZED VIEW in place, since it's harmless and allows delivering a more specific error message about the unsupported feature. I'm committing this separately to ease identification of what should be reverted when/if we are able to re-enable the feature. http://git.postgresql.org/pg/commitdiff/3223b25ff737c2bf4a642c0deb7be2b30bfecc6e
  • Back out some recent translation updates. Very old versions of msgfmt choke on these specific messages, for reasons that are unclear at the moment. Remove them so that we can ship a beta release and not get complaints from testers (these messages will just go untranslated, instead, and we're hardly at 100% coverage anyway). Peter Eisentraut will look for a better fix later. http://git.postgresql.org/pg/commitdiff/5da5798004e90b14332918e7db702271442d465d
  • Move materialized views' is-populated status into their pg_class entries. Previously this state was represented by whether the view's disk file had zero or nonzero size, which is problematic for numerous reasons, since it's breaking a fundamental assumption about heap storage. This was done to allow unlogged matviews to revert to unpopulated status after a crash despite our lack of any ability to update catalog entries post-crash. However, this poses enough risk of future problems that it seems better to not support unlogged matviews until we can find another way. Accordingly, revert that choice as well as a number of existing kluges forced by it in favor of creating a pg_class.relispopulated flag column. http://git.postgresql.org/pg/commitdiff/1d6c72a55b23554cfb946527dc77f9d80044ae2c
  • Desultory copy-editing of the 9.3 release notes. I had time for a quick review of the notes, so here are some fixes. http://git.postgresql.org/pg/commitdiff/f1ff90cfb1c5168cd442593de62b419ac9ab6469
  • Stamp 9.3beta1. http://git.postgresql.org/pg/commitdiff/817a89423f429a6a8b36847ee499f5b6be39c3be
  • Better fix for permissions tests in excluded subqueries. This reverts the code changes in 50c137487c96e629e0e5372bb3d1b5f1a2f71a88, which turned out to induce crashes and not completely fix the problem anyway. That commit only considered single subqueries that were excluded by constraint-exclusion logic, but actually the problem also exists for subqueries that are appendrel members (ie part of a UNION ALL list). In such cases we can't add a dummy subpath to the appendrel's AppendPath list without defeating the logic that recognizes when an appendrel is completely excluded. Instead, fix the problem by having setrefs.c scan the rangetable an extra time looking for subqueries that didn't get into the plan tree. (This approach depends on the 9.2 change that made set_subquery_pathlist generate dummy paths for excluded single subqueries, so that the exclusion behavior is the same for single subqueries and appendrel members.) Note: it turns out that the appendrel form of the missed-permissions-checks bug exists as far back as 8.4. However, since the practical effect of that bug seems pretty minimal, consensus is to not attempt to fix it in the back branches, at least not yet. Possibly we could back-port this patch once it's gotten a reasonable amount of testing in HEAD. For the moment I'm just going to revert the previous patch in 9.2. http://git.postgresql.org/pg/commitdiff/a7b965382cf0cb30aeacb112572718045e6d4be7
  • Update collate.linux.utf8.out for ruleutils.c line-wrapping changes. Missed in commit 62e666400dddf605b9b6d9a7ac2918711b5c5629. http://git.postgresql.org/pg/commitdiff/284e28f2280a8f69014df689ae5e2843eebd7c59
  • Use pg_dump's --quote-all-identifiers option in pg_upgrade. This helps guard against changes in the set of reserved keywords from one version to another. In theory it should only be an issue if we de-reserve a keyword in a newer release, since that can create the type of problem shown in bug #8128. Back-patch to 9.1 where the --quote-all-identifiers option was added. http://git.postgresql.org/pg/commitdiff/1c36700e9e3cfb96fde636def87cafb57299f4da
  • Fix management of fn_extra caching during repeated GiST index scans. Commit d22a09dc70f9830fa78c1cd1a3a453e4e473d354 introduced official support for GiST consistentFns that want to cache data using the FmgrInfo fn_extra pointer: the idea was to preserve the cached values across gistrescan(), whereas formerly they'd been leaked. However, there was an oversight in that, namely that multiple scan keys might reference the same column's consistentFn; the code would result in propagating the same cache value into multiple scan keys, resulting in crashes or wrong answers. Use a separate array instead to ensure that each scan key keeps its own state. Per bug #8143 from Joel Roller. Back-patch to 9.2 where the bug was introduced. http://git.postgresql.org/pg/commitdiff/91715e82932665c6e125d100eeaa1b6debf73e7b
  • Fix pgp_pub_decrypt() so it works for secret keys with passwords. Per report from Keith Fiske. Marko Kreen http://git.postgresql.org/pg/commitdiff/477b5a0e24f3b62a470f9684e22e36a2c7735274
  • Guard against input_rows == 0 in estimate_num_groups(). This case doesn't normally happen, because the planner usually clamps all row estimates to at least one row; but I found that it can arise when dealing with relations excluded by constraints. Without a defense, estimate_num_groups() can return zero, which leads to divisions by zero inside the planner as well as assertion failures in the executor. An alternative fix would be to change set_dummy_rel_pathlist() to make the size estimate for a dummy relation 1 row instead of 0, but that seemed pretty ugly; and probably someday we'll want to drop the convention that the minimum rowcount estimate is 1 row. Back-patch to 8.4, as the problem can be demonstrated that far back. http://git.postgresql.org/pg/commitdiff/69cc60dcfd0fb643cd2fe3ce66d4389858bfdeb5
  • Update CREATE FUNCTION documentation about argument names. The 9.2 patch that added argument name support in SQL-language functions missed updating a parenthetical comment about that in the CREATE FUNCTION reference page. Noted by Erwin Brandstetter. http://git.postgresql.org/pg/commitdiff/c263f16a20a12ee63bbf0c4769d87db3184709eb
  • Make pg_upgrade's test script attempt to select a non-conflicting port. Previously, the port number used in this test script was hard-wired at pg_upgrade's default of 50432; which is not so great because parallel build runs might conflict. Commit 3d53173e20d151341f894f79d556768c845ba3e4 removed this setting for the postmasters started by the script proper (not by pg_upgrade), which didn't do anything to fix that problem and also guaranteed a failure if there was a live postmaster at the build's default port number. Instead, select a non-conflicting temporary port number in the same way that pg_regress.c does. (Its method isn't entirely bulletproof, but given the lack of complaints I'm not going to worry about that today.) In passing, unset MAKEFLAGS and MAKELEVEL to avoid problems with the script's internal invocations of make, for the same reason pg_regress.c does: it could cause problems in a parallel make. http://git.postgresql.org/pg/commitdiff/7e2b1c03ce24e8fefa2080c0f1f8cfbb86ce664e
  • Fix buildfarm incompatibility in updated pg_upgrade test script. Looks like some versions of the buildfarm script try to set the port via --port in $EXTRA_REGRESS_OPTS. Override that ... http://git.postgresql.org/pg/commitdiff/8cade04c105f2d31c941bee9716a304f93a41351
  • Fix to_number() to correctly ignore thousands separator when it's '.'. The existing code in NUM_numpart_from_char has hard-wired logic to treat '.' as decimal point, even when we're using a locale-aware format string and the locale says that '.' is the thousands separator. This results in clearly wrong answers in Fujii Masao mode (where we must be able to identify the decimal point location), as per bug report from Patryk Kordylewski. Since the initialization code in NUM_prepare_locale already sets up Np->decimal as either the locale decimal-point string or "." depending on which decimal-point format code was used, there's really no need to have any extra logic at all in NUM_numpart_from_char: we only need to test for a match to Np->decimal. (Note: AFAICS there's nothing in here that explicitly checks for thousands separators --- rather, any unmatched character is silently skipped over. That's pretty bogus IMO but it's not the issue being complained of.) This is a longstanding bug, but it's possible that some existing apps are depending on '.' being recognized as decimal point even when using a D format code. Hence, no back-patch. We should probably list this as a potential incompatibility in the 9.3 release notes. http://git.postgresql.org/pg/commitdiff/35d50b527a9f99e22a317269ceb00491397d0e00
  • Fix handling of strict non-set functions with NULLs in set-valued inputs. In a construct like "select plain_function(set_returning_function(...))", the plain function is applied to each output row of the SRF successively. If some of the SRF outputs are NULL, and the plain function is strict, you'd expect to get NULL results for such rows ... but what actually happened was that such rows were omitted entirely from the result set. This was due to confusion of this case with what should happen for nested set-returning functions; a strict SRF is indeed supposed to yield an empty set for null input. Per bug #8150 from Erwin Brandstetter. Although this has been broken forever, we're not back-patching because of the possibility that some apps out there expect the incorrect behavior. This change should be listed as a possible incompatibility in the 9.3 release notes. http://git.postgresql.org/pg/commitdiff/904af8db8a99409257db1eed0b056c8098e9013c

Heikki Linnakangas a poussé :

  • Stress that backup_label file is critical in the docs. It is surprisingly common mistake to leave out backup_label file from a base backup. Say more explicitly that it must be included. Jeff Janes, with minor rewording by me. http://git.postgresql.org/pg/commitdiff/7f03a791fa131eb20c6df07740522163d8b3c94e
  • Use the term "radix tree" instead of "suffix tree" for SP-GiST text opclass. What we have implemented is a radix tree (or a radix trie or a patricia trie), but the docs and code comments incorrectly called it a "suffix tree". Alexander Korotkov http://git.postgresql.org/pg/commitdiff/cb953d8b1bf7386ff20300cd80b29b7e8657dcbd
  • Fix walsender failure at promotion. If a standby server has a cascading standby server connected to it, it's possible that WAL has already been sent up to the next WAL page boundary, splitting a WAL record in the middle, when the first standby server is promoted. Don't throw an assertion failure or error in walsender if that happens. Also, fix a variant of the same bug in pg_receivexlog: if it had already received WAL on previous timeline up to a segment boundary, when the upstream standby server is promoted so that the timeline switch record falls on the previous segment, pg_receivexlog would miss the segment containing the timeline switch. To fix that, have walsender send the position of the timeline switch at end-of-streaming, in addition to the next timeline's ID. It was previously assumed that the switch happened exactly where the streaming stopped. Note: this is an incompatible change in the streaming protocol. You might get an error if you try to stream over timeline switches, if the client is running 9.3beta1 and the server is more recent. It should be fine after a reconnect, however. Reported by Fujii Masao. http://git.postgresql.org/pg/commitdiff/2ffa66f4975c99e52984f7ee81b47d137b5b4751
  • The data structure used in unaccent is a trie, not suffix tree. Fix the term used in variable and struct names, and comments. Alexander Korotkov http://git.postgresql.org/pg/commitdiff/4b06c1820a1b96769ea7447a0fc8e0edabbf57f5

Peter Eisentraut a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Dimitri Fontaine sent in a patch to add an example of using the event trigger API to the documentation.
  • Christoph Berg sent in a patch to add EXTRA_REGRESS_OPTS to all pg_regress invocations.
  • Simon Riggs sent in a patch to allow pg_dump to use a snapshot exported with an explicit pg_export_snapshot() for when precise timing of the snapshot is important.
  • Christoph Berg sent in a patch to fix the fact that PSQLDIR was not passed to pg_regress in contrib/pg_upgrade/test.sh.
  • Robins Tharakan sent in another revision of a patch to add some regression tests for SEQUENCE.
  • Robins Tharakan sent in two more revisions of a patch to add regression tests for SCHEMA.
  • Robins Tharakan sent in another revision of a patch to add regression tests for ROLE.
  • Robins Tharakan sent in two more revisions of a patch to add regression tests for COLLATE.
  • Robert Haas sent in another revision of a patch to fix a case where it was possible to do an erroneous restore into the pg_catalog schema.
  • Amul Sul sent in a patch to fix an issue where psql connection reset failed.
  • Simon Riggs sent in a patch to fix a bug where VACUUM was no longer reporting "removed %d row versions."
  • Fabien COELHO sent in two more revisions of a patch to add a --throttle option to pgbench.
  • Fabien COELHO sent in another revision of a patch to add a --progress option to pgbench.
  • Fabien COELHO sent in another revision of a patch to add long options to pgbench.
  • Robins Tharakan sent in a patch to add regression tests for DISCARD.
  • Robins Tharakan sent in a patch to cover more database commands, raising the code coverage from 36% to 71%.

par N Bougain le mercredi 15 mai 2013 à 23h25

mardi 14 mai 2013

Actualités PostgreSQL.fr

Sortie de PostgreSQL 9.3 bêta 1

La première version bêta de PostgreSQL 9.3, la dernière mouture de la meilleure base de données open source, est disponible. Cette bêta vous donnera un avant-goût de toutes les fonctionnalités qui seront disponibles dans la version 9.3. Vous pouvez d'ores et déjà commencer les tests de validation.

Téléchargez cette version, essayez-la et déclarez les éventuels problèmes que vous découvrez !

Principales nouveautés :

Les fonctionnalités à tester en priorité sont les suivantes :

  • Écriture sur des tables distantes (Writeable Foreign Tables) et envoi des données sur des systèmes de stockage externes
  • Fédérer des bases PostgreSQL avec le connecteur pgsql_fdw
  • Mettre à jour des vues automatiquement
  • Créer des vues matérialisées
  • Tester les jointures latérales (LATERAL JOIN)
  • Utiliser les nouvelles fonctions JSON
  • Indexation pour la recherche par expressions rationnelles
  • Checksums des pages disque pour détecter les erreurs du systèmes de fichiers

Avec les version 9.3, PostgreSQL a réduit drastiquement son utilisation des mémoires partagées SysV au profit de mmap. Ceci permet une installation et une configuration plus facile. Cependant cela implique que les utilisateurs de PostgreSQL testent cette nouveauté de manière rigoureuse et s'assurent qu'aucun problème de mémoire n'est apparu.

Les utilisateurs de PostgreSQL sont également invités à tester attentivement les améliorations des verrous sur clefs étrangères ("Foreign Key Locks")

Fonctionnalités supplémentaires

Ce n'est pas tout. Cette version apporte encore plus de nouveautés, notamment :

  • Bascules d'urgence rapides (Failover) vers un serveur secondaire pour garantir la haute disponibilité de vos données
  • Reconstruction d'un serveur secondaire uniquement via streaming
  • Améliorations des verrous sur clefs étrangères
  • pg_dump en parallèle pour des sauvegardes plus rapides
  • Un dossier pour les fichiers de configuration
  • Sonde pg_isready pour vérifier la disponibilité d'une base
  • Option COPY FREEZE pour réduire les entrées/sorties en cas de chargement massif
  • Processus en arrière-plan définis par l'utilisateur pour effectuer des taches automatisées
  • Déclaration de vues récursives
  • Directive lock_timeout

La liste complète des avancées de la version 9.3 bêta est disponible dans la note de publication (en anglais) : http://www.postgresql.org/docs/deve...

Pour plus de détails et des exemples, rendez-vous sur la page wiki des nouveautés de PostgreSQL 9.3 (en anglais) : http://wiki.postgresql.org/wiki/Wha...

Testez PostgreSQL 9.3 bêta 1 dès maintenant !

La qualité et les performances de PostgreSQL dépendent de l'implication de sa communauté dans les tests des versions bêta.

Téléchargez PostgreSQL 9.3 Beta 1 et essayez-la dès que possible dans vos environnements et avec vos applications. Et envoyez vos commentaires aux développeurs de PostgreSQL.

Les fonctionnalités et les API de la version bêta 1 ne changeront pas d'ici la sortie de la version finale. Vous pouvez donc commencer à développer des applications dès maintenant avec cette version.

Plus d'information sur la façon de tester et remonter un problème : http://www.postgresql.org/developer...

Vous pouvez obtenir les binaires et les installeurs Windows, Linux et Mac sur la page de téléchargement : http://www.postgresql.org/download

La documentation de la nouvelle version est disponible http://www.postgresql.org/docs/deve...

Lien vers l'annonce officielle: http://www.postgresql.org/about/new...

par daamien le mardi 14 mai 2013 à 13h16

jeudi 9 mai 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 5 mai 2013

Offres d'emplois autour de PostgreSQL en mai

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

Simon Riggs a poussé :

Robert Haas a poussé :

  • Attempt to fix error recovery in COPY BOTH mode. Previously, libpq and the backend had opposite ideas about whether it was necessary for the client to send a CopyDone message after receiving an ErrorResponse, making it impossible to cleanly exit COPY BOTH mode. Fix libpq so that works correctly, adopting the backend's notion that an ErrorResponse kills the copy in both directions. Adjust receivelog.c to avoid a degradation in the quality of the resulting error messages. libpqwalreceiver.c is already doing the right thing, so no adjustment needed there. Add an explicit statement to the documentation explaining how this part of the protocol is supposed to work, in the hopes of avoiding future confusion in this area. Since the consequences of all this confusion are very limited, especially in the back-branches where no client ever attempts to exit COPY BOTH mode without closing the connection entirely, no back-patch. http://git.postgresql.org/pg/commitdiff/91fa8532f4053468acc08534a6aac516ccde47b7

Kevin Grittner a poussé :

  • Ensure ANALYZE phase is not skipped because of canceled truncate. Patch b19e4250b45e91c9cbdd18d35ea6391ab5961c8d attempted to preserve existing behavior regarding statistics generation in the case that a truncation attempt was canceled due to lock conflicts. It failed to do this accurately in two regards: (1) autovacuum had previously generated statistics if the truncate attempt failed to initially get the lock rather than having started the attempt, and (2) the VACUUM ANALYZE command had always generated statistics. Both of these changes were unintended, and are reverted by this patch. On review, there seems to be consensus that the previous failure to generate statistics when the truncate was terminated was more an unfortunate consequence of how that effort was previously terminated than a feature we want to keep; so this patch generates statistics even when an autovacuum truncation attempt terminates early. Another unintended change which is kept on the basis that it is an improvement is that when a VACUUM command is truncating, it will the new heuristic for avoiding blocking other processes, rather than keeping an AccessExclusiveLock on the table for however long the truncation takes. Per multiple reports, with some renaming per patch by Jeff Janes. Backpatch to 9.0, where problem was created. http://git.postgresql.org/pg/commitdiff/5fc893760f60d57aca30163796db1abe516b3fac
  • Add regression test for bug fixed by recent refactoring. Test case by Andres Freund for bug fixed by Tom Lane's refactoring in commit 5194024d72f33fb209e10f9ab0ada7cc67df45b7 http://git.postgresql.org/pg/commitdiff/200ba1667b3a8d7a9d559d2f05f83d209c9d8267
  • Prevent (auto)vacuum from truncating first page of populated matview. Per report from Fujii Masao, with regression test using his example. http://git.postgresql.org/pg/commitdiff/b69ec7cc990fd8da75ed4c232899503217d7b9ae

Tom Lane a poussé :

  • Postpone creation of pathkeys lists to fix bug #8049. This patch gets rid of the concept of, and infrastructure for, non-canonical PathKeys; we now only ever create canonical pathkey lists. The need for non-canonical pathkeys came from the desire to have grouping_planner initialize query_pathkeys and related pathkey lists before calling query_planner. However, since query_planner didn't actually *do* anything with those lists before they'd been made canonical, we can get rid of the whole mess by just not creating the lists at all until the point where we formerly canonicalized them. There are several ways in which we could implement that without making query_planner itself deal with grouping/sorting features (which are supposed to be the province of grouping_planner). I chose to add a callback function to query_planner's API; other alternatives would have required adding more fields to PlannerInfo, which while not bad in itself would create an ABI break for planner-related plugins in the 9.2 release series. This still breaks ABI for anything that calls query_planner directly, but it seems somewhat unlikely that there are any such plugins. I had originally conceived of this change as merely a step on the way to fixing bug #8049 from Teun Hoogendoorn; but it turns out that this fixes that bug all by itself, as per the added regression test. The reason is that now get_eclass_for_sort_expr is adding the ORDER BY expression at the end of EquivalenceClass creation not the start, and so anything that is in a multi-member EquivalenceClass has already been created with correct em_nullable_relids. I am suspicious that there are related scenarios in which we still need to teach get_eclass_for_sort_expr to compute correct nullable_relids, but am not eager to risk destabilizing either 9.2 or 9.3 to fix bugs that are only hypothetical. So for the moment, do this and stop here. Back-patch to 9.2 but not to earlier branches, since they don't exhibit this bug for lack of join-clause-movement logic that depends on em_nullable_relids being correct. (We might have to revisit that choice if any related bugs turn up.) In 9.2, don't change the signature of make_pathkeys_for_sortclauses nor remove canonicalize_pathkeys, so as not to risk more plugin breakage than we have to. http://git.postgresql.org/pg/commitdiff/db9f0e1d9a4a0842c814a464cdc9758c3f20b96c
  • Fix permission tests for views/tables proven empty by constraint exclusion. A view defined as "select <something> where false" had the curious property that the system wouldn't check whether users had the privileges necessary to select from it. More generally, permissions checks could be skipped for tables referenced in sub-selects or views that were proven empty by constraint exclusion (although some quick testing suggests this seldom happens in cases of practical interest). This happened because the planner failed to include rangetable entries for such tables in the finished plan. This was noticed in connection with erroneous handling of materialized views, but actually the issue is quite unrelated to matviews. Therefore, revert commit 200ba1667b3a8d7a9d559d2f05f83d209c9d8267 in favor of a more direct test for the real problem. Back-patch to 9.2 where the bug was introduced (by commit 7741dd6590073719688891898e85f0cb73453159). http://git.postgresql.org/pg/commitdiff/50c137487c96e629e0e5372bb3d1b5f1a2f71a88
  • Improve SPI documentation about null-flags arrays. Clarify the description of nulls[] arguments, and use the same wording for all SPI functions with this type of argument. Per gripe from Yuriy Rusinov. http://git.postgresql.org/pg/commitdiff/c091c431979c182bc835b345655c1c162479aeb3
  • Improve behavior of \watch with non-tuple-returning commands. Print the command tag if we get PGRES_COMMAND_OK, and throw an error for other cases. Per gripe from Michael Paquier. In passing, add an fflush(), just to be real sure the output appears before we sleep. http://git.postgresql.org/pg/commitdiff/626e6eda4f605788110bfc5fa95760305f7eb749

Peter Eisentraut a poussé :

Andrew Dunstan a poussé :

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Fabien COELHO sent in four revisions of a patch to add a --throttle option to pgbench.
  • Peter Eisentraut sent in a PoC patch to allow back branches to compile with gcc 4.8.0 and higher.
  • Kevin Grittner and Tom Lane swapped patches intended to iron out remaining "stop ship" bugs in materialized views.
  • Jeff Davis sent in a patch to fix some issues in page checksums.
  • Fabien COELHO sent in a patch to add a --progress option to pgbench.
  • Fabien COELHO sent in a patch to add long options to pgbench.
  • Fujii Masao sent in a patch to clarify the usage of the --idempotent option in pg_ctl.

par N Bougain le jeudi 9 mai 2013 à 14h30

Nouvelles hebdomadaires de PostgreSQL - 28 avril 2013

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en avril

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

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

Simon Riggs a poussé :

Kevin Grittner a poussé :

  • Fix assertion failure for REFRESH MATERIALIZED VIEW in PL. This was due to incomplete implementation of rowcount reporting for RMV, which was due to initial waffling on whether it should be provided. It seems unlikely to be a useful or universally available number as more sophisticated techniques for maintaining matviews are added, so remove the partial support rather than completing it. Per report of Jeevan Chalke, but with a different fix http://git.postgresql.org/pg/commitdiff/63e20041a2b5f98fdfe6b32af9550ca54ff8649f

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Avoid deadlock between concurrent CREATE INDEX CONCURRENTLY commands. There was a high probability of two or more concurrent C.I.C. commands deadlocking just before completion, because each would wait for the others to release their reference snapshots. Fix by releasing the snapshot before waiting for other snapshots to go away. Per report from Paul Hinze. Back-patch to all active branches. http://git.postgresql.org/pg/commitdiff/c3d09b3bd23f5f65b5eb8124a3c7592dad85a50c
  • Incidental cleanup of matviews code. Move checking for unscannable matviews into ExecOpenScanRelation, which is a better place for it first because the open relation is already available (saving a relcache lookup cycle), and second because this eliminates the problem of telling the difference between rangetable entries that will or will not be scanned by the query. In particular we can get rid of the not-terribly-well-thought-out-or-implemented isResultRel field that the initial matviews patch added to RangeTblEntry. Also get rid of entirely unnecessary scannability check in the rewriter, and a bogus decision about whether RefreshMatViewStmt requires a parse-time snapshot. catversion bump due to removal of a RangeTblEntry field, which changes stored rules. http://git.postgresql.org/pg/commitdiff/5194024d72f33fb209e10f9ab0ada7cc67df45b7
  • Fix collation assignment for aggregates with ORDER BY. ORDER BY expressions were being treated the same as regular aggregate arguments for purposes of collation determination, but really they should not affect the aggregate's collation at all; only collations of the aggregate's regular arguments should affect it. In many cases this mistake would lead to incorrectly throwing a "collation conflict" error; but in some cases the corrected code will silently assign a different collation to the aggregate than before, for example agg(foo ORDER BY bar COLLATE "x") which will now use foo's collation rather than "x" for the aggregate. Given this risk and the lack of field complaints about the issue, it doesn't seem prudent to back-patch. In passing, rearrange code in assign_collations_walker so that we don't need multiple copies of the standard logic for computing collation of a node with children. (Previously, CaseExpr duplicated the standard logic, and we would have needed a third copy for Aggref without this change.) Andrew Gierth and David Fetter http://git.postgresql.org/pg/commitdiff/41a2760f611d1b3c1e67f755baf0a052b5cec9af
  • Fix unsafe event-trigger coding in ProcessUtility(). We mustn't run any of the event-trigger support code when handling utility statements like START TRANSACTION or ABORT, because that code may need to refresh event-trigger cache data, which requires being inside a valid transaction. (This mistake explains the consistent build failures exhibited by the CLOBBER_CACHE_ALWAYS buildfarm members, as well as some irreproducible failures on other members.) The least messy fix seems to be to break standard_ProcessUtility into two functions, one that handles all the statements not supported by event triggers, and one that contains the event-trigger support code and handles the statements that are supported by event triggers. This change also fixes several inconsistencies, such as four cases where support had been installed for "ddl_event_start" but not "ddl_event_end" triggers, plus the fact that InvokeDDLCommandEventTriggersIfSupported() paid no mind to isCompleteQuery. Dimitri Fontaine and Tom Lane http://git.postgresql.org/pg/commitdiff/5525e6c40bbda351a19b48317eba0f79aa32e447
  • Editorialize a bit on new ProcessUtility() API. Choose a saner ordering of parameters (adding a new input param after the output params seemed a bit random), update the function's header comment to match reality (cmon folks, is this really that hard?), get rid of useless and sloppily-defined distinction between PROCESS_UTILITY_SUBCOMMAND and PROCESS_UTILITY_GENERATED. http://git.postgresql.org/pg/commitdiff/f8db76e875099e5e49f5cd729a673e84c0b0471b

Robert Haas a poussé :

Joe Conway a poussé :

  • Ensure that user created rows in extension tables get dumped if the table is explicitly requested, either with a -t/--table switch of the table itself, or by -n/--schema switch of the schema containing the extension table. Patch reviewed by Vibhor Kumar and Dimitri Fontaine. Backpatched to 9.1 when the extension management facility was added. http://git.postgresql.org/pg/commitdiff/b42ea7981ce1e7484951a22662937541066d8647

Correctifs rejetés (à ce jour)

  • Ashutosh Bapat's patch to infer GROUP BY dependencies through views. To Tom Lane, this looked like an impossible job to do correctly.

Correctifs en attente

  • Ants Aasma, Jeff Davis, and Simon Riggs traded more patches to implement checksums.
  • Timothy Garnett sent in two different approaches to allowing pg_restore in parallel from a pipe.
  • KONDO Mitsumasa and Heikki Linnakangas traded patches to fix an issue in standby recovery.
  • Andres Freund sent in a patch to re-add missing time.h include in psql/command.c which had been removed upon the addition of the \watch psql command.
  • Kevin Grittner sent in a patch to fix a statistics problem related to vacuum truncation termination.
  • David Fetter sent in another revision of a patch to implent FILTER clauses pursuant to a COLLATE-related bug fix in master.
  • Tom Lane sent in a patch to fix bug 8049.

par N Bougain le jeudi 9 mai 2013 à 14h19

mercredi 8 mai 2013

Guillaume Lelarge

Nouvelles versions mineures de la documentation

Désolé, encore une fois, j'ai mis du temps avant de me coller à la mise à jour de la traduction des manuels. C'est fait, c'est disponible, pour les version 8.4 à 9.2.

La version beta de la 9.3 devrait sortir demain. Je m'y colle dès demain soir. Ça risque d'être épique, comme à chaque mise à jour majeure :) Quoique, après avoir regardé le diff, ça ne semble pas si dur que ça. Sont principalement touchées la documentation sur les fonctions, la configuration, les catalogues (rien que de l'habituel jusqu'ici), ainsi que les triggers sur événement, les vues matérialisées, les Foreign Data Wrapper, pg_xlogdump, pg_isready et les Background Workers (les grosses nouveautés de cette version). N'empêche qu'il y a du boulot.

par Guillaume Lelarge le mercredi 8 mai 2013 à 14h57

mardi 23 avril 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 21 avril 2013

PGConf.DE 2013 est la suite de la très réussie PostgreSQL Conference 2011 germanophone. Nous gardons le concept : 8 novembre 2013 au musée industriel de la Rhénanie à Oberhausen : http://2013.pgconf.de/

Le programme du PG Day France 2013 est disponible, et les inscriptions sont ouvertes. Cet événement aura lieu à Nantes le 13 juin 2013. Programme : http://pgday.fr/programme Inscriptions : http://www.pgday.fr/inscriptions

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en avril

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

Tom Lane a poussé :

  • Improve GiST index search performance for trigram regex queries. The initial coding just descended the index if any of the target trigrams were possibly present at the next level down. But actually we can apply trigramsMatchGraph() so as to take advantage of AND requirements when there are some. The input data might contain false positive matches, but that can only result in a false positive result, not false negative, so it's safe to do it this way. Alexander Korotkov http://git.postgresql.org/pg/commitdiff/410bed2ab8c3864d7f34f9694d080adcaf446352
  • Don't try to pass -I switch to postmaster in contrib/start-scripts/linux. Undo thinko in commit 87306184580c9c49717b00d48a2f9e717f21e0a8. Per bug #8098 from Catherine Devlin. http://git.postgresql.org/pg/commitdiff/3353583d7ecf7c9f8bc5966ed0a2537dec71ffdc
  • Improve error message when an FDW doesn't support WHERE CURRENT OF. If an FDW fails to take special measures with a CurrentOfExpr, we will end up trying to execute it as an ordinary qual, which was being treated as a purely internal failure condition. Provide a more user-oriented error message for such cases. http://git.postgresql.org/pg/commitdiff/6e481ebff6368cb0ab5351a5ef3463747c35af22
  • Fix longstanding race condition in plancache.c. When creating or manipulating a cached plan for a transaction control command (particularly ROLLBACK), we must not perform any catalog accesses, since we might be in an aborted transaction. However, plancache.c busily saved or examined the search_path for every cached plan. If we were unlucky enough to do this at a moment where the path's expansion into schema OIDs wasn't already cached, we'd do some catalog accesses; and with some more bad luck such as an ill-timed signal arrival, that could lead to crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya. Fortunately, there's no real need to consider the search path for such commands, so we can just skip the relevant steps when the subject statement is a TransactionStmt. This is somewhat related to bug #5269, though the failure happens during initial cached-plan creation rather than revalidation. This bug has been there since the plan cache was invented, so back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/ac63dca607e8e22247defbc8fe03b6baa3628c42

Andrew Dunstan a poussé :

Peter Eisentraut a poussé :

Heikki Linnakangas a poussé :

Bruce Momjian a poussé :

Robert Haas a poussé :

Correctifs rejetés (à ce jour)

  • Colin 't Hart's patch to add \ns as a short cut for SET search_path in psql.

Correctifs en attente

  • Simon Riggs sent in three revisions of a patch to optimize COPY for some kinds of volatile expressions.
  • Bruce Momjian sent in a patch to reformat pg_test_fsync's output in a more compact way.
  • Robert Haas sent in a patch to prevent pg_restore from restoring into the pg_catalog schema by accident.
  • Ants Aasma sent in two more revisions of a patch to implement page checksums, including variously optimizable algorithms for same.
  • Fabrízio de Royes Mello sent in two revisions of a patch to include currval() for discarding in DISCARD ALL.

par N Bougain le mardi 23 avril 2013 à 00h02

Nouvelles hebdomadaires de PostgreSQL - 14 avril 2013

Premier rassemblement utilisateurs/développeurs Postgres-XC après le Cluster Summit : https://wiki.postgresql.org/wiki/PgCon2013CanadaClusterSummit#PostgresXC_Summit

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en avril

PostgreSQL Local

  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. Il aura lieu le 13 juin 2013 à Nantes (France) : http://pgday.fr/
  • Les appels à conférenciers pour le Char(13) et le PGday UK, respectivement les 11 et 12 juillet 2013, sont lancés et seront clos le 19 avril 2013. Pour le Char(13), écrivez à speakers AT char13 DOT info ; pour le PGday UK, speakers AT postgresqlusergroup DOT org DOT uk.
  • PostgreSQL Brazil aura lieu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil : http://pgbr.postgresql.org.br/2013/chamada.en.php
  • Notez la date ! Postgres Open 2013 aura lieu à Chicago (Illinois, USA) du 16 au 18 septembre. Hotel Sax : https://reservations.ihotelier.com/crs/g_reservation.cfm?groupID=888761&hotelID=6865 Inscriptions pour les lève-tôt : http://postgresopen-eac2.eventbrite.com/
  • La PGConf.EU 2013 sera tenue du 29 octobre au 1er novembre au Conrad Hotel dans le centre-ville de Dublin en Irlande : http://2013.pgconf.eu/

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

Simon Riggs a poussé :

Heikki Linnakangas a poussé :

Tom Lane a poussé :

  • Support indexing of regular-expression searches in contrib/pg_trgm. This works by extracting trigrams from the given regular expression, in generally the same spirit as the previously-existing support for LIKE searches, though of course the details are far more complicated. Currently, only GIN indexes are supported. We might be able to make it work with GiST indexes later. The implementation includes adding API functions to backend/regex/ to provide a view of the search NFA created from a regular expression. These functions are meant to be generic enough to be supportable in a standalone version of the regex library, should that ever happen. Alexander Korotkov, reviewed by Heikki Linnakangas and Tom Lane http://git.postgresql.org/pg/commitdiff/3ccae48f44d993351e1f881761bd6c556ebd6638
  • Make contrib/pg_trgm also support regex searches with GiST indexes. This wasn't addressed in the original patch, but it doesn't take very much additional code to cover the case, so let's get it done. Since pg_trgm 1.1 hasn't been released yet, I just changed the definition of what's in it, rather than inventing a 1.2. http://git.postgresql.org/pg/commitdiff/6f5b8beb64d481c28a483090d10099c8d619c797
  • Clean up the mess around EXPLAIN and materialized views. Revert the matview-related changes in explain.c's API, as per recent complaint from Robert Haas. The reason for these appears to have been principally some ill-considered choices around having intorel_startup do what ought to be parse-time checking, plus a poor arrangement for passing it the view parsetree it needs to store into pg_rewrite when creating a materialized view. Do the latter by having parse analysis stick a copy into the IntoClause, instead of doing it at runtime. (On the whole, I seriously question the choice to represent CREATE MATERIALIZED VIEW as a variant of SELECT INTO/CREATE TABLE Alexander Shulgin, because that means injecting even more complexity into what was already a horrid legacy kluge. However, I didn't go so far as to rethink that choice ... yet.) I also moved several error checks into matview parse analysis, and made the check for external Params in a matview more accurate. In passing, clean things up a bit more around interpretOidsOption(), and fix things so that we can use that to force no-oids for views, sequences, etc, thereby eliminating the need to cons up "oids = false" options when creating them. catversion bump due to change in IntoClause. (I wonder though if we really need readfuncs/outfuncs support for IntoClause anymore.) http://git.postgresql.org/pg/commitdiff/0b337904213337db5026ef0a756a447588023935

Robert Haas a poussé :

Kevin Grittner a poussé :

  • Create a distinction between a populated matview and a scannable one. The intent was that being populated would, long term, be just one of the conditions which could affect whether a matview was scannable; being populated should be necessary but not always sufficient to scan the relation. Since only CREATE and REFRESH currently determine the scannability, names and comments accidentally conflated these concepts, leading to confusion. Also add missing locking for the SQL function which allows a test for scannability, and fix a modularity violatiion. Per complaints from Tom Lane, although its not clear that these will satisfy his concerns. Hopefully this will at least better frame the discussion. http://git.postgresql.org/pg/commitdiff/52e6e33ab495cb2b0e694ee480ba7c6394315053

Andrew Dunstan a poussé :

Alvaro Herrera a poussé :

Magnus Hagander a poussé :

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Etsuro Fujita sent in a patch to remove unused targets from the tlist.
  • KaiGai Kohei sent in a flock of patches to improve sepgsql.
  • Ants Aasma and Simon Riggs traded patches to improve page checksums.
  • Jeff Davis sent in two more patches to clarify and improve page checksums.
  • Christoph Berg sent in a patch to pg_regress accept --host=/tmp.
  • Jeff Janes sent in a patch to improve autovacuum's locking behavior.
  • Miguel Angel de Blas Burdalo sent in a patch to creat a function SPI_gettypmod(), which returns a field's typemod from a TupleDesc.
  • Robins Tharakan sent in a patch to add regression tests for COLLATE.
  • Dimitri Fontaine sent in another revision of a patch to improve and clarify the sql_drop event for event triggers feature.
  • Heikki Linnakangas sent in a patch to reduce the memory usage of index relcache entries.
  • Stephen Frost sent in a patch to modify ExecChooseHashTableSize() so it ignore NTUP_PER_BUCKET, essentially treating it as 1, when work_mem is large enough to fit the entire hash table, which also implies that there is only one batch.

par N Bougain le mardi 23 avril 2013 à 00h00

vendredi 19 avril 2013

Actualités PostgreSQL.fr

Trouver récursivement les blocages entre sessions.

Problématique

C'est quelque chose qu'on rencontre régulièrement en production: une session idle in transaction qui a un verrou sur quelque chose, qui bloque une autre sesssion qui veut acquérir un verrou dessus. Cette autre session a elle même un verrou sur un autre objet, qui bloque une troisième session, et ainsi de suite.

À résoudre à la main, c'est toujours pénible. Pas compliqué, mais ça prend du temps, dans un contexte où on a souvent quelques utilisateurs bloqués qui vous râlent dans les oreilles, voire un chef qui vous souffle dans le cou, pour les plus malchanceux.

Solution

On doit donc pouvoir résoudre ça avec une requête qui, pour chaque session bloquée, remonte les verrous jusqu'à la source du problème. En espérant ne pas m'être trompé, voici une requête qui fait exactement ça (testée sur un cas raisonnablement simple en 9.2): En m'étant bien trompé, voici une version améliorée (j'espère que cette fois-ci c'est bon, j'ai eu un cas réel pour la tester).

with recursive conflicting_locks(lock,conflicts) as
  (
    values ('AccessShareLock','{"AccessExclusiveLock"}'::text[]),
           ('RowShareLock','{"AccessExclusiveLock","ExclusiveLock"}'),
           ('RowExclusiveLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareLock"}'),
           ('ShareUpdateExclusiveLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareLock","ShareUpdateExclusiveLock"}'),
           ('ShareLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareUpdateExclusiveLock","RowExclusiveLock"}'),
           ('ShareRowExclusiveLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareLock","ShareUpdateExclusiveLock","RowExclusiveLock"}'),
           ('ExclusiveLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareLock","ShareUpdateExclusiveLock","RowExclusiveLock","RowShareLock"}'),
           ('AccessExclusiveLock','{"AccessExclusiveLock","ExclusiveLock","ShareRowExclusiveLock","ShareLock","ShareUpdateExclusiveLock","RowExclusiveLock","RowShareLock","AccessShareLock"}')
  ),
    tmplocks(pid,lockingpid,lock,granted) as
  (
   select distinct l.pid, rl.pid as lockingpid, coalesce(l.relation::text,l.virtualxid::text,l.transactionid::text) as lock ,rl.granted
   from pg_locks rl
   join pg_locks l
     on (coalesce(rl.relation::text,rl.virtualxid::text,rl.transactionid::text)=coalesce(l.relation::text,l.virtualxid::text,l.transactionid::text)
         and rl.pid<>l.pid)
   where l.granted
   and not rl.granted
   and l.locktype <> 'tuple' and rl.locktype <> 'tuple'
   and exists (SELECT 1 FROM conflicting_locks WHERE conflicting_locks.lock=l.mode AND rl.mode=ANY(conflicting_locks.conflicts))
),
   locks (pid,lockingpid,tree) as
  (
        select pid,lockingpid,'{}'::int[]||pid from tmplocks where not granted
        UNION ALL
        select tmplocks.pid,tmplocks.lockingpid,tree || tmplocks.pid from tmplocks join locks on (tmplocks.pid=locks.lockingpid)
  )
select tree||lockingpid as wholockswho from locks limit 1000000

Pour les curieux, voila comment elle fonctionne:

La première CTE, conflicting_locks, définit quel lock est en conflit avec un tableau des autres

La deuxième CTE, tmplocks, retourne tous les verrous non accordés (not granted), le pid de celui qui est bloqué, le pid de celui qui possède le verrou, et le verrou. On utilise conflicting_locks pour vérifier que les verrous sont en conflits, et on ignore les verrous de type type (ils sont temporaires, et ne devraient pas engendrer de conflit).

La troisième fait la récursion: pour chaque session verrouillée, on détermine qui la verrouille. Si celle qui verrouille est elle même verrouillée, on continue la récursion. On stocke dans «tree» les pid de la récursion.

Le select final rajoute à tree le pid final (qui n'a pas été stocké durant la récursion, puisque lui n'est pas bloqué).

Voila le résultat que j'obtiens dans mon environnement de test:

  wholockswho  |  treelock  
---------------+------------
 {7993,5179}   | {16160479}
 {23390,4245}  | {16154891}
 {20285,23384} | {16158008}
 {32125,23389} | {16161532}
 {23390,21069} | {16154891}
 {23390,9236}  | {16154891}
 {3556,23393}  | {16164983}
 {17780,7982}  | {16156626}
 {23386,23372} | {16158053}
 {7988,21070}  | {16155665}
 {466,6498}    | {16163682}
 {23390,21158} | {16154891}
 {3556,464}    | {16164983}
 {7993,19567}  | {16160479}
 {13206,32122} | {16158730}
 {3556,5170}   | {16164983}
 {23390,24163} | {16154891}
 {6499,3121}   | {16165246}
 {23390,7990}  | {16154891}
 {21065,20438} | {16153879}
 {23390,23394} | {16154891}
 {21065,23385} | {16153879}
 {23390,24164} | {16154891}
 {23286,3554}  | {16161392}
 {23390,32111} | {16154891}
 {3556,6497}   | {16164983}
 {23386,7994}  | {16158053}
 {21065,17795} | {16153879}
 {20285,5176}  | {16158008}
 {6499,32127}  | {16165246}
 {6499,21063}  | {16165246}
 {23390,20442} | {16154891}
 {7789,6500}   | {16166302}
 {12749,465}   | {16159721}
 {5174,24166}  | {16163923}
 {23390,5173}  | {16154891}
 {466,32000}   | {16163682}

On voit que le pid 23390 en gène un bon paquet d'autres. C'est un bon candidat à l'extermination (c'est une session IDLE in transaction…)

Si vous voyez des cas que j'ai raté, ou une amélioration de cette requête, n'hésitez pas à poster en-dessous…

par mcousin le vendredi 19 avril 2013 à 14h45

mercredi 17 avril 2013

Actualités PostgreSQL.fr

PG Day France 2013 : une journée de conférences sur le SGBD PostgreSQL

Le 13 juin à Nantes se tiendra le PG Day France 2013, une journée de conférences et d'échanges sur le thème du SGBDR open source PostgreSQL. Cette journée sera également l'occasion de rencontrer les acteurs de la communauté PostgreSQL.

Que vous soyez DBA, architecte, développeur, chef de projet utilisant PostgreSQL, vous découvrirez des retours d'expérience d'autres utilisateurs, ainsi que des présentations techniques de PostgreSQL, de PostGIS (cartouche spatiale) ou d'autres extensions. Cette journée est organisée par la communauté francophone des utilisateurs de PostGreSQL, avec le soutien de plusieurs entreprises partenaires (SMILE, Dalibo).

Inscrivez-vous dès à présent, et retrouvez les informations complémentaires sur le site : http://www.pgday.fr/

Le programme des conférences comporte les sujets suivants :

  • Gestion de la capacité des ressources mémoire par Cédric Villemain
  • Nouveautés de PostgreSQL 9.3 (30 min) par Damien Clochard
  • Ma base de données tiendrait-elle la charge ? par Philippe Beaudouin
  • PostGIS 2.x et au delà par Hugo Mercier
  • OMM versus ORM par Grégoire HUBERT
  • Vers le Peta Byte avec PostgreSQL par Dimitri Fontaine
  • Comprendre EXPLAIN par Guillaume Lelarge
  • Requêtes LATERALes par Vik Fearing

Le nombre de places est limité. Inscrivez-vous vite à cette adresse :

http://www.pgday.fr/inscriptions

Rendez-vous à Nantes le 13 juin !

par daamien le mercredi 17 avril 2013 à 08h45

samedi 13 avril 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 7 avril 2013

Les mises à jour de sécurité : 9.2.4, 9.1.9, 9.0.13 et 8.4.17 sont disponibles. Mettez à jour immédiatement, si pas plus tôt ! http://www.postgresql.org/about/news/1456/
FAQ à propos de ces MAJ : http://www.postgresql.org/support/security/faq/2013-04-04/
[ndt: page traduite : http://www.postgresql.fr/faq_correctif_20130404]

La PGConf.EU 2013 sera tenue du 29 octobre au 1er novembre au Conrad Hotel dans le centre-ville de Dublin en Irlande : http://2013.pgconf.eu/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en avril

PostgreSQL Local

  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. Il aura lieu le 13 juin 2013 à Nantes (France) : http://pgday.fr/
  • Les appels à conférenciers pour le Char(13) et le PGday UK, respectivement les 11 et 12 juillet 2013, sont lancés et seront clos le 19 avril 2013. Pour le Char(13), écrivez à speakers AT char13 DOT info ; pour le PGday UK, speakers AT postgresqlusergroup DOT org DOT uk.
  • PostgreSQL Brazil aura lieu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil : http://pgbr.postgresql.org.br/2013/chamada.en.php
  • Notez la date ! Postgres Open 2013 aura lieu à Chicago (Illinois, USA) du 16 au 18 septembre. Hotel Sax : https://reservations.ihotelier.com/crs/g_reservation.cfm?groupID=888761&hotelID=6865 Inscriptions pour les lève-tôt : http://postgresopen-eac2.eventbrite.com/

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

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Make REPLICATION privilege checks test current user not authenticated user. The pg_start_backup() and pg_stop_backup() functions checked the privileges of the initially-authenticated user rather than the current user, which is wrong. For example, a user-defined index function could successfully call these functions when executed by ANALYZE within autovacuum. This could allow an attacker with valid but low-privilege database access to interfere with creation of routine backups. Reported and fixed by Noah Misch. Security: CVE-2013-1901 http://git.postgresql.org/pg/commitdiff/ce9ab88981495d975aade8fc664f99f68fc18e2b
  • Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state. http://git.postgresql.org/pg/commitdiff/f7b0006f42913b6d641c9f0bef6fad1f670b9194
  • Fix typo in FDW docs. Laurenz Albe http://git.postgresql.org/pg/commitdiff/0f1345d38b4d7b35175d4f4be322da0aa6d6aaeb
  • Minor robustness improvements for isolationtester. Notice and complain about PQcancel() failures. Also, don't dump core if an error PGresult doesn't contain severity and message subfields, as it might not if it was generated by libpq itself. (We have a longstanding TODO item to improve that, but in the meantime isolationtester had better cope.) I tripped across the latter item while investigating a trouble report on buildfarm member spoonbill. As for the former, there's no evidence that PQcancel failure is actually involved in spoonbill's problem, but it still seems like a bad idea to ignore an error return code. http://git.postgresql.org/pg/commitdiff/845d335a90b684dd51e80a6470ebb923a59a1f91
  • Update release notes for 9.2.4, 9.1.9, 9.0.13, 8.4.17. Security: CVE-2013-1899, CVE-2013-1901 http://git.postgresql.org/pg/commitdiff/89b661bab99e8573fad271f68755ba286932dec2
  • Fix insecure parsing of server command-line switches. An oversight in commit e710b65c1c56ca7b91f662c63d37ff2e72862a94 allowed database names beginning with "-" to be treated as though they were secure command-line switches; and this switch processing occurs before client authentication, so that even an unprivileged remote attacker could exploit the bug, needing only connectivity to the postmaster's port. Assorted exploits for this are possible, some requiring a valid database login, some not. The worst known problem is that the "-r" switch can be invoked to redirect the process's stderr output, so that subsequent error messages will be appended to any file the server can write. This can for example be used to corrupt the server's configuration files, so that it will fail when next restarted. Complete destruction of database tables is also possible. Fix by keeping the database name extracted from a startup packet fully separate from command-line switches, as had already been done with the user name field. The Postgres project thanks Mitsumasa Kondo for discovering this bug, Kyotaro Horiguchi for drafting the fix, and Noah Misch for recognizing the full extent of the danger. Security: CVE-2013-1899 http://git.postgresql.org/pg/commitdiff/17fe2793ea7fe269ed616cb305150b6cf38dbaa8
  • Improve documentation about the relationship of extensions and schemas. There's been some confusion expressed about this point, so clarify. Extended version of a patch by David Wheeler. http://git.postgresql.org/pg/commitdiff/52f436b807b0d02203ea6be19bafa56e4e1381e8
  • Fix line count in slashUsage(). Counting newlines shows that quite a few recent patches have neglected to update the output-lines count given to PageOutput(). Fortunately it's not terribly critical that this be exact, since we long since exceeded the height of most people's terminal windows. Still, maybe we ought to think of a way to not have to maintain this manually anymore. http://git.postgresql.org/pg/commitdiff/927e1dc96ce3eb4a618fd7b67f69eec72b56d850
  • Add \watch [SEC] command to psql. This allows convenient re-execution of commands. Will Leinweber, reviewed by Peter Eisentraut, Daniel Farina, and Tom Lane http://git.postgresql.org/pg/commitdiff/c6a3fce7dd4dae6e1a005e5b09cdd7c1d7f9c4f4
  • In isolationtester, retry after EINTR return from select(2). Per report from Jaime Casanova. Very curious that no one else has seen this failure ... but the code is clearly wrong as-is. http://git.postgresql.org/pg/commitdiff/faf4726c9fd5748ad25dbce55a7d31deeabe9866
  • Get rid of USE_WIDE_UPPER_LOWER dependency in trigram construction. contrib/pg_trgm's make_trigrams() was coded to ignore multibyte character boundaries and just make trigrams from bytes if USE_WIDE_UPPER_LOWER wasn't defined. This is a bit odd, since there's no obvious reason why trigram compaction rules should depend on the presence of towlower() and friends. What's more, there was an Assert() that would fail if that code path was fed any multibyte characters. We need to do something about this since the pending regex-indexing patch has an assumption that you get just one "trgm" from any three characters. The best solution seems to be to remove the USE_WIDE_UPPER_LOWER dependency, which shouldn't really have been there in the first place. The second loop in make_trigrams() is now just a fast path and not a potentially incompatible algorithm. If there is anybody still using Postgres on machines without wcstombs() or towlower(), and they have non-ASCII data indexed by pg_trgm, they'll need to REINDEX those indexes after pg_upgrade to 9.3, else searches may fail incorrectly. It seems likely that there are no such installations, though. In passing, rename cnt_trigram to compact_trigram, which seems to better describe its functionality, and improve make_trigrams' test for whether it has to use the slow path or not (per a suggestion from Alexander Korotkov). http://git.postgresql.org/pg/commitdiff/7844608e54a3a2e3dee461b00fd6ef028a845d7c

Heikki Linnakangas a poussé :

Andrew Dunstan a poussé :

Bruce Momjian a poussé :

Robert Haas a poussé :

Simon Riggs a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Jeff Janes sent in another revision of a patch to add a --startup option to pgbench.
  • Tom Lane sent in a patch to fix some mis-estimation of the costs of hash joins.
  • Alexander Korotkov and Tom Lane, with contributions of performance numbers from Erik Rijkers, sent in more revisions of the patch to allow indexing DFA regexes.
  • Jeff Janes sent in another revision of a patch to change the units of spinlock_delay to microseconds.
  • Dimitri Fontaine sent in two more revisions of a patch to add extension templates.
  • Andres Freund sent in a patch to add option for dumping full page writes to pg_dump.
  • Michael Paquier sent in a patch to fix a typo in the documentation for JSON functions.
  • Heikki Linnakangas sent in a patch to ensure that enough WAL segments are kept in situations where they might not have been.
  • Heikki Linnakangas sent in a patch to prevent backend crashes with certain unusual regexes.
  • Simon Riggs, Andres Freund and Jeff Davis traded patches to fix some corner cases in the page checksum code.
  • Grzegorz Jaskiewicz and Robert Haas traded patches to remove some formatting dead code.
  • Kevin Grittner sent in a patch to fix some scannability issues in materialized views.
  • Jeff Janes sent in a patch to help ensure that the right WALs get saved.
  • Jeff Janes sent in a patch to ensure that the process title of the autovacuum worker reflects what it's doing at the time.
  • Tomas Vondra sent in a patch to implement pg_stat_agg_database.

par N Bougain le samedi 13 avril 2013 à 11h50

jeudi 11 avril 2013

Stephane Bortzmeyer

RFC 6922: The application/sql Media Type

Premier enregistrement d'un nouveau type de données (type MIME) fait depuis les nouvelles règles du RFC 6838, ce RFC enregistre un type très ancien mais qui n'avait jamais été normalisé, "application/sql", pour le code source SQL.

jeudi 11 avril 2013 à 00h00

dimanche 7 avril 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 31 mars 2013

Le projet PostgreSQL va publier une mise à jour de sécurité le jeudi 4 avril pour toutes les versions supportées. Cette publication incluera un correctif pour une vulnérabilité très exposée. Tous les utilisateurs sont fortement poussés à appliquer la mise à jour aussitôt que possible : http://www.postgresql.org/about/news/1454/
Page en français : http://blog.postgresql.fr/index.php?post/2013/04/02/Mise-%C3%A0-jour-importante-%C3%A0-pr%C3%A9voir-le-4-avril-!

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. Il aura lieu le 13 juin 2013 à Nantes (France) : http://pgday.fr/
  • The CfPs for Char(13) and PGday UK, July 11 and 12, 2013, respectively, are out and close April 19, 2013. For Char(13), write speakers AT char13 DOT info; for PGday UK, speakers AT postgresqlusergroup DOT org DOT uk.
  • PostgreSQL Brazil aura lieu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil : http://pgbr.postgresql.org.br/2013/chamada.en.php
  • Notez la date ! Postgres Open 2013 aura lieu à Chicago (Illinois, USA) du 16 au 18 septembre. Hotel Sax : https://reservations.ihotelier.com/crs/g_reservation.cfm?groupID=888761&hotelID=6865 Early Bird registration: http://postgresopen-eac2.eventbrite.com/

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

  • Add missing #include. time(2) requires time.h. http://git.postgresql.org/pg/commitdiff/4eefd0f86b6ce2e657c566fe40301930ab31eddd
  • In base backup, only include our own tablespace version directory. If you have clusters of different versions pointing to the same tablespace location, we would incorrectly include all the data belonging to the other versions, too. Fixes bug #7986, reported by Sergey Burladyan. http://git.postgresql.org/pg/commitdiff/28ba260906c87ffbda42f93d867191f491025a04
  • Make pg_basebackup work with pre-9.3 servers, and add server version check. A new 'starttli' field was added to the response of BASE_BACKUP command. Make pg_basebackup tolerate the case that it's missing, so that it still works with older servers. Add an explicit check for the server version, so that you get a nicer error message if you try to use it with a pre-9.1 server. The streaming protocol message format changed in 9.3, so -X stream still won't work with pre-9.3 servers. I added a version check to ReceiveXLogStream() earlier, but write that slightly differently, so that in 9.4, it will still work with a 9.3 server. (In 9.4, the error message needs to be adjusted to "9.3 or above", though). Also, if the version check fails, don't retry. http://git.postgresql.org/pg/commitdiff/d298b50a3b469c088bb40a4d36d38111b4cd574d
  • Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt. Per warning from -Wmissing-format-attribute. http://git.postgresql.org/pg/commitdiff/ea988ee8c8b191615e730f930bcde6144a598688
  • Get rid of obsolete parse_version helper function. For getting the server's version in numeric form, use PQserverVersion(). It does the exact same parsing as dumputils.c's parse_version(), and has been around in libpq for a long time. For the client's version, just use the PG_VERSION_NUM constant. http://git.postgresql.org/pg/commitdiff/901b89e37bb8e71224ee76987679010ff3c93c05
  • Fix pg_dump against 9.1/9.2 servers. The parallel pg_dump patch forgot to add relpages column to 9.1/9.2 version of the getTables() query. Reported by Bernd Helmle. http://git.postgresql.org/pg/commitdiff/625b237f79ec59369e6083f041649adf4fdc1080
  • Move some pg_dump function around. Move functions used only by pg_dump and pg_restore from dumputils.c to a new file, pg_backup_utils.c. dumputils.c is linked into psql and some programs in bin/scripts, so it seems good to keep it slim. The parallel functionality is moved to parallel.c, as is exit_horribly, because the interesting code in exit_horribly is parallel-related. This refactoring gets rid of the on_exit_msg_func function pointer. It was problematic, because a modern gcc version with -Wmissing-format-attribute complained if it wasn't marked with PF_PRINTF_ATTRIBUTE, but the ancient gcc version that Tom Lane's old HP-UX box has didn't accept that attribute on a function pointer, and gave an error. We still use a similar function pointer trick for getLocalPQBuffer() function, to use a thread-local version of that in parallel mode on Windows, but that dodges the problem because it doesn't take printf-like arguments. http://git.postgresql.org/pg/commitdiff/7800a71291690dcc34eb3b7aab18750b5a7ebe2c
  • Fix buffer pin leak in heap update redo routine. In a heap update, if the old and new tuple were on different pages, and the new page no longer existed (because it was subsequently truncated away by vacuum), heap_xlog_update forgot to release the pin on the old buffer. This bug was introduced by the "Fix multiple problems in WAL replay" patch, commit 3bbf668de9f1bc172371681e80a4e769b6d014c8 (on master branch). With full_page_writes=off, this triggered an "incorrect local pin count" error later in replay, if the old page was vacuumed. This fixes bug #7969, reported by Yunong Xiao. Backpatch to 9.0, like the commit that introduced this bug. http://git.postgresql.org/pg/commitdiff/3cfb572dde2095df1bfc6665862dcf8ee0a95b99

Andrew Dunstan a poussé :

  • Fix a small logic bug in adjusted parallel restore code. http://git.postgresql.org/pg/commitdiff/ec143f94051779bb5d07419723529b4cc4fcce95
  • Add new JSON processing functions and parser API. The JSON parser is converted into a recursive descent parser, and exposed for use by other modules such as extensions. The API provides hooks for all the significant parser event such as the beginning and end of objects and arrays, and providing functions to handle these hooks allows for fairly simple construction of a wide variety of JSON processing functions. A set of new basic processing functions and operators is also added, which use this API, including operations to extract array elements, object fields, get the length of arrays and the set of keys of a field, deconstruct an object into a set of key/value pairs, and create records from JSON objects and arrays of objects. Catalog version bumped. Andrew Dunstan, with some documentation assistance from Merlin Moncure. http://git.postgresql.org/pg/commitdiff/a570c98d7fa0841f17bbf51d62d02d9e493c7fcc
  • Fix page title for JSON Functions and Operators. http://git.postgresql.org/pg/commitdiff/6caf759f3f34eb496f4a92c3db9d3289299066b9
  • Avoid moving data directory in upgrade testing. Windows sometimes gets upset if we rename a large directory and then try to use the old name quickly, as seen in occasional buildfarm failures. So we avoid that by building the old version in the intended destination in the first place instead of renaming it, similar to the change made for the same reason in commit b7f8465c. http://git.postgresql.org/pg/commitdiff/67eb3e5075b52bb9d91dc3bd9358ac1da2ded5fc

Tom Lane a poussé :

  • Ignore invalid indexes in pg_dump. Dumping invalid indexes can cause problems at restore time, for example if the reason the index creation failed was because it tried to enforce a uniqueness condition not satisfied by the table's data. Also, if the index creation is in fact still in progress, it seems reasonable to consider it to be an uncommitted DDL change, which pg_dump wouldn't be expected to dump anyway. Back-patch to all active versions, and teach them to ignore invalid indexes in servers back to 8.2, where the concept was introduced. Michael Paquier http://git.postgresql.org/pg/commitdiff/683abc73dff549e94555d4020dae8d02f32ed78b
  • Fix grammatical errors in some new message strings. Daniele Varrazzo http://git.postgresql.org/pg/commitdiff/f7f210b5c4c9c76e87fffc5abef7dea752d1ac9a
  • Reset OpenSSL randomness state in each postmaster child process. Previously, if the postmaster initialized OpenSSL's PRNG (which it will do when ssl=on in postgresql.conf), the same pseudo-random state would be inherited by each forked child process. The problem is masked to a considerable extent if the incoming connection uses SSL encryption, but when it does not, identical pseudo-random state is made available to functions like contrib/pgcrypto. The process's PID does get mixed into any requested random output, but on most systems that still only results in 32K or so distinct random sequences available across all Postgres sessions. This might allow an attacker who has database access to guess the results of "secure" operations happening in another session. To fix, forcibly reset the PRNG after fork(). Each child process that has need for random numbers from OpenSSL's generator will thereby be forced to go through OpenSSL's normal initialization sequence, which should provide much greater variability of the sequences. There are other ways we might do this that would be slightly cheaper, but this approach seems the most future-proof against SSL-related code changes. This has been assigned CVE-2013-1900, but since the issue and the patch have already been publicized on pgsql-hackers, there's no point in trying to hide this commit. Back-patch to all supported branches. Marko Kreen http://git.postgresql.org/pg/commitdiff/0d1ecd6300191a450978ca2fcd12bbbb7c5e65e6
  • Avoid "variable might be clobbered by longjmp" warning. On older-model gcc, the original coding of UTILITY_BEGIN_QUERY() can draw this error because of multiple assignments to _needCleanup. Rather than mark that variable volatile, we can suppress the warning by arranging to have just one unconditional assignment before PG_TRY. http://git.postgresql.org/pg/commitdiff/58bc48179b3cad0793ae20b002d60289c8bf0b9b
  • Update time zone data files to tzdata release 2013b. DST law changes in Chile, Haiti, Morocco, Paraguay, some Russian areas. Historical corrections for numerous places. http://git.postgresql.org/pg/commitdiff/ae7f1c3ef2eef9584e3c9a42c395eb0c0e59a5ed
  • Draft release notes for 9.2.4, 9.1.9, 9.0.13, 8.4.17. Covers commits through today. Not back-patching into back branches yet, since this is just for people to review in advance. http://git.postgresql.org/pg/commitdiff/29505a894e1ece60bf42a2756ae99c9e44b5ae6a
  • Must check indisready not just indisvalid when dumping from 9.2 server. 9.2 uses a kluge representation of "indislive"; we have to account for that when examining pg_index. Simplest solution is to check indisready for 9.0 and 9.1 as well; that's harmless though unnecessary, so it's not worth making a version distinction for. Fixes oversight in commit 683abc73dff549e94555d4020dae8d02f32ed78b, as noted by Andres Freund. http://git.postgresql.org/pg/commitdiff/aa02864f64c46807f7682a41882fe40f7f5cb819
  • Document encode(bytea, 'escape')'s behavior correctly. I changed this in commit fd15dba543247eb1ce879d22632b9fdb4c230831, but missed the fact that the SGML documentation of the function specified exactly what it did. Well, one of the two places where it's specified documented that --- probably I looked at the other place and thought nothing needed to be done. Sync the two places where encode() and decode() are described. http://git.postgresql.org/pg/commitdiff/9ad27c215362df436f8c16f1aace923011f31be4
  • Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan. http://git.postgresql.org/pg/commitdiff/22f7b9613e5a60bc3daca35f87f546baa9fd934c
  • Ignore extra subquery outputs in set_subquery_size_estimates(). In commit 0f61d4dd1b4f95832dcd81c9688dac56fd6b5687, I added code to copy up column width estimates for each column of a subquery. That code supposed that the subquery couldn't have any output columns that didn't correspond to known columns of the current query level --- which is true when a query is parsed from scratch, but the assumption fails when planning a view that depends on another view that's been redefined (adding output columns) since the upper view was made. This results in an assertion failure or even a crash, as per bug #8025 from lindebg. Remove the Assert and instead skip the column if its resno is out of the expected range. http://git.postgresql.org/pg/commitdiff/d931ac0ec4c25b61f480562a13f1974f913afd59
  • Update release notes for changes through today. http://git.postgresql.org/pg/commitdiff/e48a7bd527481556f7068832331ef6b00805920b

Robert Haas a poussé :

Simon Riggs a poussé :

Kevin Grittner a poussé :

Alvaro Herrera a poussé :

  • Add sql_drop event for event triggers. This event takes place just before ddl_command_end, and is fired if and only if at least one object has been dropped by the command. (For instance, DROP TABLE IF EXISTS of a table that does not in fact exist will not lead to such a trigger firing). Commands that drop multiple objects (such as DROP SCHEMA or DROP OWNED BY) will cause a single event to fire. Some firings might be surprising, such as ALTER TABLE DROP COLUMN. The trigger is fired after the drop has taken place, because that has been deemed the safest design, to avoid exposing possibly-inconsistent internal state (system catalogs as well as current transaction) to the user function code. This means that careful tracking of object identification is required during the object removal phase. Like other currently existing events, there is support for tag filtering. To support the new event, add a new pg_event_trigger_dropped_objects() set-returning function, which returns a set of rows comprising the objects affected by the command. This is to be used within the user function code, and is mostly modelled after the recently introduced pg_identify_object() function. Catalog version bumped due to the new function. Dimitri Fontaine and Álvaro Herrera Review by Robert Haas, Tom Lane http://git.postgresql.org/pg/commitdiff/473ab40c8bb3fcb1a7645f6a7443a0424d70fbaf

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Amit Kapila sent in another revision of a patch to allow postgresql.conf values to be changed via SQL.
  • Joe Conway sent a patch for git master and back-patches for 9.1 and 9.2 to correct situations where pg_dump selectively ignores extension configuration tables.
  • Jeff Davis sent in a patch to fix an issue where the page checksum patch broke the regression tests.
  • Steve Singer sent in another revision of a patch to fix an issue where an invalid PGSERVICE setting broke pg_upgrade.
  • Brendan Jurd sent in another revision of a patch to remove "zero-dimensional arrays" from the code.
  • Michael Paquier sent in two more revisions of a patch to add REINDEX CONCURRENTLY.
  • Pavel Stehule sent in another revision of a patch to implement plpgsql_check_function.
  • Heikki Linnakangas sent a patch to document the fact that pg_basebackup needs to be told specifically about anything located outside $PGDATA.
  • Amit Kapila sent in another revision of a patch to improve update performance by reducing the amount of WAL written for same.
  • Dickson S. Guedes sent in a patch to fix some examples in the JSON docs.

par N Bougain le dimanche 7 avril 2013 à 19h09

Nouvelles hebdomadaires de PostgreSQL - 24 mars 2013

L'appel à conférenciers pour le Char(13) et le PGday UK, respectivement les 11 et 12 juillet 2013, sont lancés et seront clos le 19 avril 2013. Pour le Char(13), écrivez à speakers AT char13 DOT info ; pour le PGday UK, speakers AT postgresqlusergroup DOT org DOT uk.

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

Simon Riggs a poussé :

Tom Lane a poussé :

  • Improve documentation of EXTRACT(WEEK). The docs showed that early-January dates can be considered part of the previous year for week-counting purposes, but failed to say explicitly that late-December dates can also be considered part of the next year. Fix that, and add a cross-reference to the "isoyear" field. Per bug #7967 from Pawel Kobylak. http://git.postgresql.org/pg/commitdiff/e39feb1006ac5c64fd804597088bc7f40ff7b635
  • Bump up timeout delays some more in timeouts isolation test. The buildfarm members using -DCLOBBER_CACHE_ALWAYS still don't like this test. Some experimentation shows that on my machine, isolationtester's query to check for "waiting" state takes 2 to 2.5 seconds to bind+execute under -DCLOBBER_CACHE_ALWAYS. Set the timeouts to 5 seconds to leave some headroom for possibly-slower buildfarm critters. Really we ought to fix the "waiting" query, which is not only horridly slow but outright wrong in detail; and then maybe we can back off these timeouts. But right now I'm just trying to get the buildfarm green again. http://git.postgresql.org/pg/commitdiff/a7921f71a3c747141344d8604f6a6d7b4cddb2a9
  • Redo postgres_fdw's planner code so it can handle parameterized paths. I wasn't going to ship this without having at least some example of how to do that. This version isn't terribly bright; in particular it won't consider any combinations of multiple join clauses. Given the cost of executing a remote EXPLAIN, I'm not sure we want to be very aggressive about doing that, anyway. In support of this, refactor generate_implied_equalities_for_indexcol so that it can be used to extract equivalence clauses that aren't necessarily tied to an index. http://git.postgresql.org/pg/commitdiff/9cbc4b80ddc10b36c64514104caa69747c386dcf
  • Avoid retrieving dummy NULL columns in postgres_fdw. This should provide some marginal overall savings, since it surely takes many more cycles for the remote server to deal with the NULL columns than it takes for postgres_fdw not to emit them. But really the reason is to keep the emitted queries from looking quite so silly ... http://git.postgresql.org/pg/commitdiff/e690b9515072fd7767fdeca5c54166f6a77733bc
  • Update commit_delay documentation. Commit 13fe298ca06f5390df5edf073cf401f9f0b67458 changed this GUC to be PGC_SUSET, but neglected to update the documentation to match. While at it, edit and rearrange the text a little for clarity. http://git.postgresql.org/pg/commitdiff/82b945c0979350c87ddc52adefe9f0a36dd5b4c8
  • Suppress uninitialized-variable warning in new checksum code. Some compilers understand that this coding is safe, and some don't. http://git.postgresql.org/pg/commitdiff/4912385b56afe68ef76e47d38df1d61ada0fde2f
  • Fix contrib/dblink to handle inconsistent DateStyle/IntervalStyle safely. If the remote database's settings of these GUCs are different from ours, ambiguous datetime values may be read incorrectly. To fix, temporarily adopt the remote server's settings while we ingest a query result. This is not a complete fix, since it doesn't do anything about ambiguous values in commands sent to the remote server; but there seems little we can do about that end of it given dblink's entirely textual API for transmitted commands. Back-patch to 9.2. The hazard exists in all versions, but this patch would need more work to apply before 9.2. Given the lack of field complaints about this issue, it doesn't seem worth the effort at present. Daniel Farina and Tom Lane http://git.postgresql.org/pg/commitdiff/8a3b6772aedbd95557ab1fc489ddf007ac9d405d
  • Document cross-version compatibility issues for contrib/postgres_fdw. One of the use-cases for postgres_fdw is extracting data from older PG servers, so cross-version compatibility is important. Document what we can do here, and further annotate some of the coding choices that create compatibility constraints. In passing, remove one unnecessary incompatibility with old servers, namely assuming that we didn't need to quote the timezone name 'UTC'. http://git.postgresql.org/pg/commitdiff/5b86fedfb57ea943f883a13c6d50c5a9e2a1cc57
  • Don't put <indexterm> before <term> in <varlistentry> items. Doing that results in a broken index entry in PDF output. We had only a few like that, which is probably why nobody noticed before. Standardize on putting the <term> first. Josh Kupershmidt http://git.postgresql.org/pg/commitdiff/cdc67938c086104ef7a0e2f1e6912e9ee0ba4c85
  • Update time zone abbreviation lists for changes missed since 2006. Most (all?) of Russia has moved to what's effectively year-round daylight savings time, so that the "standard" zone names now mean an hour later than they used to. Update that, notably changing MSK as per recent complaint from Sergey Konoplev, but also CHOT, GET, IRKT, KGT, KRAT, MAGT, NOVT, OMST, VLAT, YAKT, YEKT. The corresponding DST abbreviations are presumably now obsolete, but I left them in place with their old definitions, just to reduce any possible breakage from this change. Also add VOLT (Europe/Volgograd), which for some reason we never had before, as well as MIST (Antarctica/Macquarie), and fix obsolete definitions of MAWT, TKT, and WST. http://git.postgresql.org/pg/commitdiff/3b91fe185a71c05ac4528f93a39ba27232acc9e0
  • Semi-automatically detect changes in timezone abbreviations. Add an option to zic.c to dump out all non-obsolete timezone abbreviations defined in the Olson database. Comparing this list to its previous state will clue us in when something happens that we may need to account for in the tznames/ time zone abbreviation lists. The README file's previous exhortation to "just grep for differences" was completely useless advice, in my now-considerable experience; but maybe this will be a bit more useful. As a starting point I built the same list from the tzdata files as they existed in 2006, which is committed here as known_abbrevs.txt. Comparison indeed turned up quite a few changes we had neglected to account for, which I will commit separately. http://git.postgresql.org/pg/commitdiff/69602772700e62b7b03e3f0ac7b10aa651c0c998
  • Fix some unportable constructs in parallel pg_dump code. Didn't compile on semi-obsolete gcc, and probably not on not-gcc-at-all either. http://git.postgresql.org/pg/commitdiff/846681fdd574548d4f430f2ff7ab44d77b4c79fe

Kevin Grittner a poussé :

Alvaro Herrera a poussé :

  • Allow extracting machine-readable object identity Introduce pg_identify_object(oid,oid,int4), which is similar in spirit to pg_describe_object but instead produces a row of machine-readable information to uniquely identify the given object, without resorting to OIDs or other internal representation. This is intended to be used in the event trigger implementation, to report objects being operated on; but it has usefulness of its own. Catalog version bumped because of the new function. http://git.postgresql.org/pg/commitdiff/f8348ea32ec8d713cd6e5d5e16f15edef22c4d03

Heikki Linnakangas a poussé :

  • Fix "element <@ range" cost estimation. The statistics-based cost estimation patch for range types broke that, by incorrectly assuming that the left operand of all range oeprators is a range. That lead to a "type x is not a range type" error. Because it took so long for anyone to notice, add a regression test for that case. We still don't do proper statistics-based cost estimation for that, so you just get a default constant estimate. We should look into implementing that, but this patch at least fixes the regression. Spotted by Tom Lane, when testing query from Josh Berkus. http://git.postgresql.org/pg/commitdiff/f897c4744fea221dfc7bbd277081edad41d1d58d

Andrew Dunstan a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Robins Tharakan sent in three more revisions of a patch to add regression tests for SCHEMA-related commands.
  • Pavel Stehule and Hadi Moshayedi traded patches to optimize avg() and friends on NUMERIC.
  • Hadi Moshayedi sent in a patch to add infrastructure which helps the above optimization, namely an aggtransspace parameter used in creating aggregate functions which approximates the size of the aggregate function's internal transition (a.k.a. state) data.
  • Steve Singer and Bruce Momjian traded patches to fix an infelicity in the handling of wrong PGSERVICE entries.
  • Nicholas White sent in four more revisions of a patch to add the ability to ignore NULLs in windowing functions per the SQL standard.
  • Michael Paquier sent in three revisions of a patch to ensure that pg_dump only dumps valid indexes.
  • Zoltan Boszormenyi sent in another revision of a patch to fix an infelicity in lock_timeout on Windows.
  • Ants Aasma sent in three revisions of a patch to implement slice-by-8 checksums on x86_64 CPUs.
  • KaiGai Kohei sent in another revision of a patch to implement OAT_POST_ALTER object access hooks.
  • Robins Tharakan sent in a patch to increase the regression tests' coverage of the ROLE code.
  • KaiGai Kohei sent in another revision of a patch to implement row-level access control.
  • Daniele Varazzo sent in some patches to fix strings for error messages in git master.
  • Alvaro Herrera sent in another revision of the dropped_objects patch vs. event triggers.
  • Brendan Jurd sent in a patch to disallow 0-dimensional arrays.
  • Andrew Dunstan sent in another revision of a patch to fix some hstore compiler warnings.
  • Alvaro Herrera sent in another revision of a patch to ensure that autovacuum sets priority on vacuums intended to prevent XID wraparound.
  • Michael Paquier sent in two revisions of a patch to ensure that custom bgworkers receive SIGHUP if the postmaster is notified.
  • Alexander Korotkov sent in another revision of a patch to make certain (DFA) regexep searches indexable.
  • Kevin Grittner sent in a patch intended to correct certain situations where pg_dump produced different results on subsequent runs from the first after a reload.
  • Adriano Lange sent in a patch to add a new optimizer, Sampling and Dynamic Programming (SDP), to PostgreSQL.
  • Michael Paquier sent in another revision of a patch to implement REINDEX CONCURRENTLY.
  • Xi Wang sent in a patch to avoid a buffer underflow in errfinish().
  • Michael Paquier sent in another revision of a patch to overhaul recovery.conf.

par N Bougain le dimanche 7 avril 2013 à 18h46

Nouvelles hebdomadaires de PostgreSQL - 17 mars 2013

Notez la date ! Postgres Open 2013 aura lieu à Chicago (Illinois, USA) du 16 au 18 septembre. Hotel Sax : https://reservations.ihotelier.com/crs/g_reservation.cfm?groupID=888761&hotelID=6865 Inscriptions pour les lève-tôt : http://postgresopen-eac2.eventbrite.com/

Les nouveautés des produits dérivés

  • E-Maj 1.0.2 publié. E-Maj est une extension PostgreSQL qui offre la possibilité de logger les updates exécutés sur un ensemble de tables, et d'annuler ces modifications au besoin, ramenant la table dans un état prédéfini : http://pgfoundry.org/projects/emaj/

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

  • Le PGDay 2013 de New-York City aura lieu le 22 mars : http://pgday.nycpug.org/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. La date limite pour les propositions de conférence est le samedi 24 mars 2013 à 23h59 CEST : http://pgday.fr/call_for_papers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • L'appel à conférenciers pour PostgreSQL Brazil, événement tenu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil, est lancé. Les propositions sont attendues jusqu'au 15 mars : http://pgbr.postgresql.org.br/2013/chamada.en.php

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

Tom Lane a poussé :

  • Fix thinko in matview patch. "break" instead of "continue" suppressed view expansion for views appearing later in the range table. Per report from Erikjan Rijkers. While at it, improve the associated comment a bit. http://git.postgresql.org/pg/commitdiff/41eef0ff75c3ea905513ae46f795c0409635fac8
  • Avoid generating bad remote SQL for INSERT ... DEFAULT VALUES. "INSERT INTO foo() VALUES ()" is invalid syntax, so don't do that. http://git.postgresql.org/pg/commitdiff/8f9cc41daf08be802933dc788517743719ee0949
  • Fix postgres_fdw's issues with inconsistent interpretation of data values. For datatypes whose output formatting depends on one or more GUC settings, we have to worry about whether the other server will interpret the value the same way it was meant. pg_dump has been aware of this hazard for a long time, but postgres_fdw needs to deal with it too. To fix data retrieval from the remote server, set the necessary remote GUC settings at connection startup. (We were already assuming that settings made then would persist throughout the remote session.) To fix data transmission to the remote server, temporarily force the relevant GUCs to the right values when we're about to convert any data values to text for transmission. This is all pretty grotty, and not very cheap either. It's tempting to think of defining one uber-GUC that would override any settings that might render printed data values unportable. But of course, older remote servers wouldn't know any such thing and would still need this logic. While at it, revert commit f7951eef89be78c50ea2241f593d76dfefe176c9, since this provides a real fix. (The timestamptz given in the error message returned from the "remote" server will now reliably be shown in UTC.) http://git.postgresql.org/pg/commitdiff/cc3f281ffb0a5d9b187e7a7b7de4a045809ff683
  • Avoid row-processing-order dependency in postgres_fdw regression test. A test intended to provoke an error on the remote side was coded in such a way that multiple rows should be updated, so the output would vary depending on which one was processed first. Per buildfarm. http://git.postgresql.org/pg/commitdiff/0247d43dd9c4ba3d2e121f98e3d5adcf769ab1e3
  • Allow default expressions to be attached to columns of foreign tables. There's still some discussion about exactly how postgres_fdw ought to handle this case, but there seems no debate that we want to allow defaults to be used for inserts into foreign tables. So remove the core-code restrictions that prevented it. While at it, get rid of the special grammar productions for CREATE FOREIGN TABLE, and instead add explicit FEATURE_NOT_SUPPORTED error checks for the disallowed cases. This makes the grammar a shade smaller, and more importantly results in much more intelligible error messages for unsupported cases. It's also one less thing to fix if we ever start supporting constraints on foreign tables. http://git.postgresql.org/pg/commitdiff/a0c6dfeecfcc860858b04617a9d96eaee1d82c66
  • Fix contrib/postgres_fdw's handling of column defaults. Adopt the position that only locally-defined defaults matter. Any defaults defined in the remote database do not affect insertions performed through a foreign table (unless they are for columns not known to the foreign table). While it'd arguably be more useful to permit remote defaults to be used, making that work in a consistent fashion requires far more work than seems possible for 9.3. http://git.postgresql.org/pg/commitdiff/50c19fc76f05124b80fc4c5d20a359c5dbf017af
  • Fix documentation oversight. Mention that PlanForeignModify's result must be copiable by copyObject. http://git.postgresql.org/pg/commitdiff/209f675f0f9094015414eee39c435ed3bf65d82a
  • Introduce less-bogus handling of collations in contrib/postgres_fdw. Treat expressions as being remotely executable only if all collations used in them are determined by Vars of the foreign table. This means that, if the foreign server gets different answers than we do, it's the user's fault for not having marked the foreign table columns with collations equivalent to the remote table's. This rule allows most simple expressions such as "var < 'constant'" to be sent to the remote side, because the constant isn't determining the collation (the Var's collation would win). There's still room for improvement, but it's hard to see how to do it without a lot more knowledge and/or assumptions about what the remote side will do. http://git.postgresql.org/pg/commitdiff/ed3ddf918b59545583a4b374566bc1148e75f593
  • Avoid inserting Result nodes that only compute identity projections. The planner sometimes inserts Result nodes to perform column projections (ie, arbitrary scalar calculations) above plan nodes that lack projection logic of their own. However, we did that even if the lower plan node was in fact producing the required column set already; which is a pretty common case given the popularity of "SELECT * FROM ...". Measurements show that the useless plan node adds non-negligible overhead, especially when there are many columns in the result. So add a check to avoid inserting a Result node unless there's something useful for it to do. There are a couple of remaining places where unnecessary Result nodes could get inserted, but they are (a) much less performance-critical, and (b) coded in such a way that it's hard to avoid inserting a Result, because the desired tlist is changed on-the-fly in subsequent logic. We'll leave those alone for now. Kyotaro Horiguchi; reviewed and further hacked on by Amit Kapila and Tom Lane. http://git.postgresql.org/pg/commitdiff/4387cf956b9eb13aad569634e0c4df081d76e2e3
  • Minor fixes for hstore_to_json_loose(). Fix unportable use of isdigit(), get rid of useless calculations. http://git.postgresql.org/pg/commitdiff/c2754991ba6e513a07c15b4058df13d58f8c55ba
  • Avoid inserting no-op Limit plan nodes. This was discussed in connection with the patch to avoid inserting no-op Result nodes, but not actually implemented therein. http://git.postgresql.org/pg/commitdiff/1a1832eb085e5bca198735e5d0e766a3cb61b8fc
  • Extend format() to handle field width and left/right alignment. This change adds some more standard sprintf() functionality to format(). Pavel Stehule, reviewed by Dean Rasheed and Kyotaro Horiguchi http://git.postgresql.org/pg/commitdiff/73e7025bd8eed941a068f0a7a71e02dca8d38d1c
  • Improve error reporting in code that checks for buffer refcount leaks. Formerly we just Assert'ed that each refcount was zero, which was quick and easy but failed to provide a good overview of what was wrong. Change the code so that we'll call PrintBufferLeakWarning() for each buffer with a nonzero refcount, and then Assert at the end of the loop. This costs nothing in runtime and might ease diagnosis of some bugs. Greg Smith, reviewed by Satoshi Nagayasu, further tweaked by me http://git.postgresql.org/pg/commitdiff/dcafdbcde1baf256891be6af77868b84889b435d
  • Improve the documentation about commit_delay. Clarify the docs explaining what commit_delay does, and add a recommendation about a useful value for it, namely half of the single-page fsync time reported by pg_test_fsync. This is informed by testing of the new-in-9.3 implementation of commit_delay; in prior versions it was far harder to arrive at a useful setting. In passing, do some wordsmithing and markup-fixing in the same general area. Also, change pg_test_fsync's default time-per-test from 2 seconds to 5. The old value was about the minimum at which the results could be taken seriously at all, and so seems a tad optimistic as a default. Peter Geoghegan, reviewed by Noah Misch; some additional editing by me http://git.postgresql.org/pg/commitdiff/70ec2f8f4392f4e3d379c2c759789d631ffeec10
  • Add lock_timeout configuration parameter. This GUC allows limiting the time spent waiting to acquire any one heavyweight lock. In support of this, improve the recently-added timeout infrastructure to permit efficiently enabling or disabling multiple timeouts at once. That reduces the performance hit from turning on lock_timeout, though it's still not zero. Zoltán Böszörményi, reviewed by Tom Lane, Stephen Frost, and Hari Babu http://git.postgresql.org/pg/commitdiff/d43837d03067487560af481474ae985df894f786
  • Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend. http://git.postgresql.org/pg/commitdiff/da5aeccf64b37a8e9bd3cb605848590595dbcbf8
  • Fix inclusions in pg_receivexlog.c. Apparently this was depending on pqsignal.h for <signal.h>. Not sure why I didn't see the failure on my other machine. http://git.postgresql.org/pg/commitdiff/c68b5eff13b97ecaaa87b24406455fafe568aa3f
  • Fix inclusions in pgbench.c. Apparently this was depending on pqsignal.h for <signal.h>. Not sure why I didn't see the failure on my other machine. http://git.postgresql.org/pg/commitdiff/8c41cb695cc5f90eee3d2226ad09016381700ca7
  • Re-include pqsignal() in libpq. We need this in non-ENABLE_THREAD_SAFETY builds, and also to satisfy the exports.txt entry; while it might be a good idea to remove the latter, I'm hesitant to do so except in the context of an intentional ABI break. At least we don't have a separately maintained source file for it anymore. http://git.postgresql.org/pg/commitdiff/b1fae823ee46a26e7e557591d659351835742537
  • initdb needs pqsignal() even on Windows. I had thought we weren't using this version of pqsignal() at all on Windows, but that's wrong --- initdb is using it (and coping with the POSIX-ish semantics of bare signal() :-(). So allow the file to be built in WIN32+FRONTEND case, and add it to the MSVC build logic. http://git.postgresql.org/pg/commitdiff/e2a203a1903367135457f12e0032626f96ef04ca
  • Use pqsignal() in contrib programs rather than calling signal(2) directly. The semantics of signal(2) are more variable than one could wish; in particular, on strict-POSIX platforms the signal handler will be reset to SIG_DFL when the signal is delivered. This demonstrably breaks pg_test_fsync's use of SIGALRM. The other changes I made are not absolutely necessary today, because the called handlers all exit the program anyway. But it seems like a good general practice to use pqsignal() exclusively in Postgres code, now that we have it available everywhere. http://git.postgresql.org/pg/commitdiff/3c07fbf40bd0276e4be02fc72cba6b1cd62da301
  • Improve signal-handler lockout mechanism in timeout.c. Rather than doing a fairly-expensive setitimer() call to prevent interrupts from happening, let's just invent a simple boolean flag that the signal handler is required to check. This is not only faster but considerably more robust than before, since the previous code effectively assumed that only ITIMER_REAL events would ever fire the SIGALRM handler, which is obviously something that can be broken easily by third-party code. Zoltán Böszörményi and Tom Lane http://git.postgresql.org/pg/commitdiff/6ac7facdd3990baf47efc124e9d7229422a06452
  • Increase timeout delays in new timeouts isolation test. Buildfarm member friarbird doesn't like this test as-committed, evidently because it's so slow that the test framework doesn't reliably notice that the backend is waiting before the timeout goes off. (This is not totally surprising, since friarbird builds with -DCLOBBER_CACHE_ALWAYS.) Increase the timeout delay from 1 second to 2 in hopes of resolving that problem. http://git.postgresql.org/pg/commitdiff/4c855750fc0ba9bd30fa397eafbfee354908bbca

Alvaro Herrera a poussé :

Kevin Grittner a poussé :

Peter Eisentraut a poussé :

Heikki Linnakangas a poussé :

  • Add cost estimation of range @> and <@ operators. The estimates are based on the existing lower bound histogram, and a new histogram of range lengths. Bump catversion, because the range length histogram now needs to be present in statistic slot kind 6, or you get an error on @> and <@ queries. (A re-ANALYZE would be enough to fix that, though) Alexander Korotkov, with some refactoring by me. http://git.postgresql.org/pg/commitdiff/59d0bf9dca58b237902c2fd1507e8bc5d54d4a63
  • Change the way UESCAPE is lexed, to reduce the size of the flex tables. The error rule used to avoid backtracking with the U&'...' UESCAPE 'x' syntax bloated the flex tables, so refactor that. This patch makes the error rule shorter, by introducing a new exclusive flex state that's entered after parsing U&'...'. This shrinks the postgres binary by about 220kB. http://git.postgresql.org/pg/commitdiff/a5ff502fceadc7c203b0d7a11b45c73f1b421f69
  • Also update psqlscan.l with the UESCAPE error rule changes. Even though this patch had no user-visible difference, better keep the code in psqlscan.l sync with the backend lexer. And of course it's nice to shrink the psql binary, too. Ecpg's version of the lexer doesn't have the error rule, it doesn't try to avoid backing up, so it doesn't need to be modified. As reminded by Tom Lane http://git.postgresql.org/pg/commitdiff/f7559c0101afa33bfb4e104036ca46adac900111

Robert Haas a poussé :

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • robins sent in three revisions of a patch to test sequences in the regression tests.
  • Jeff Davis and Ants Aasma traded patches to add page checksums.
  • Michael Paquier sent in another revision of a patch to overhaul recovery.conf.
  • Amit Kapila sent in another revision of a patch to micro-optimize pglz.
  • Michael Paquier sent in two more revisions of a patch to add REINDEX CONCURRENTLY.
  • Joe Conway sent in a patch to ensure that an extension's tables' data is only dumped in the extension's absence if named explicitly in pg_dump.
  • Michael Paquier sent in a patch to fix an assertion failure during promotion of a replica to master.
  • Zoltan Boszormenyi and Amit Kapila traded patches to allow postgresql.conf values to be changed via SQL.
  • Pavel Stehule sent in a patch to detect orphaned locks.
  • Alvaro Herrera sent in another revision of a patch to add sql_drop event triggers.
  • Alvaro Herrera sent in another revision of a patch to add in-catalog Extension Scripts and Control parameters.
  • Kevin Grittner sent in two revisions of a patch to fix an assertion failure in materialized views.
  • Hadi Moshayedi sent in a patch to improve the performance of NUMERIC's AVG().
  • Marti Raudsepp sent in a patch to fix the fact that version() mixes host and target architectures in cross-compiles.

par N Bougain le dimanche 7 avril 2013 à 18h33

samedi 6 avril 2013

Nicolas Thauvin

Oups : des tablespaces imbriqués

Imbriquer des tablespaces n'a pas vraiment de sens dans PostgreSQL surtout si on veut se prendre la tête avec des montages dans tous les sens... Mais bon c'est permis, car PostgreSQL utilise uniquement les liens symboliques dans $PGDATA/pg_tblspc pour accéder au contenu des tablespaces.

Si on veut savoir ce qu'il en est voici une requête qui montre ça.

Pour PostgreSQL <= 9.1 :

SELECT f.oid, f.spcname AS name, f.spclocation AS location,
  f.spclocation ~ ('^' || (SELECT setting FROM pg_settings
                           WHERE name = 'data_directory')) AS inside_pgdata,
  (SELECT o.spcname
   FROM pg_tablespace o
   WHERE f.spclocation ~ ('^' || o.spclocation || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY o.spclocation DESC LIMIT 1) AS parent,
  (SELECT o.spclocation
   FROM pg_tablespace o
   WHERE f.spclocation ~ ('^' || o.spclocation || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY o.spclocation DESC LIMIT 1) AS parent_location
FROM pg_tablespace f
WHERE f.spcname NOT IN ('pg_default', 'pg_global');

Pour PostgreSQL >= 9.2, la colonne spcname de pg_tablespace a été remplacée par la fonction pg_tablespace_location() :

SELECT f.oid, f.spcname AS name, pg_tablespace_location(f.oid) AS location,
  pg_tablespace_location(f.oid) ~ ('^' || (SELECT setting FROM pg_settings
                                    WHERE name = 'data_directory')) AS inside_pgdata,
  (SELECT o.spcname
   FROM pg_tablespace o
   WHERE pg_tablespace_location(f.oid) ~ ('^' || pg_tablespace_location(o.oid) || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY pg_tablespace_location(o.oid) DESC LIMIT 1) AS parent,
  (SELECT pg_tablespace_location(o.oid)
   FROM pg_tablespace o
   WHERE pg_tablespace_location(f.oid) ~ ('^' || pg_tablespace_location(o.oid) || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY pg_tablespace_location(o.oid) DESC LIMIT 1) AS parent_location
FROM pg_tablespace f
WHERE f.spcname NOT IN ('pg_default', 'pg_global');

On obtient par exemple :

  oid  |   name   |                       location                       | inside_pgdata | parent  |                 parent_location                 
-------+----------+------------------------------------------------------+---------------+---------+-------------------------------------------------
 16399 | inside   | /home/pgsql/postgresql-9.0.10/data/inside            | t             |         | 
 16400 | outside  | /home/pgsql/postgresql-9.0.10/outside                | f             |         | 
 16414 | imbrique | /home/pgsql/postgresql-9.0.10/outside/imbrique       | f             | outside | /home/pgsql/postgresql-9.0.10/outside
 16415 | rimb     | /home/pgsql/postgresql-9.0.10/outside/rimb           | f             | outside | /home/pgsql/postgresql-9.0.10/outside
 16416 | rimbimb  | /home/pgsql/postgresql-9.0.10/outside/rimb/imb       | f             | rimb    | /home/pgsql/postgresql-9.0.10/outside/rimb
 16417 | deuimb   | /home/pgsql/postgresql-9.0.10/outside/rimb/truc/2imb | f             | truc    | /home/pgsql/postgresql-9.0.10/outside/rimb/truc
 16418 | truc     | /home/pgsql/postgresql-9.0.10/outside/rimb/truc      | f             | rimb    | /home/pgsql/postgresql-9.0.10/outside/rimb
(7 rows)

Pour bien gérer ses tablespaces, l'idéal est de faire un répertoire dédié au même niveau que $PGDATA, et de créer les tablespaces dedans, avec un tablespace par répertoire sur un seul niveau :

 /home/pgsql/postgresql-9.2.4
├── data
└── tblspc
    ├── tbs_1
    ├── tbs_2
    ├── ...
    └── tbs_n

C'est plus propre et on voit tout de suite l'utilisation disque avec df : parce qu'on met des disques différents derrière, bien entendu... :)

par Orgrim le samedi 6 avril 2013 à 07h10

jeudi 4 avril 2013

Actualités PostgreSQL.fr

Mises à jour mineures de PostgreSQL : 9.2.4, 9.1.9, 9.0.13, 8.4.17

Ceci est une traduction libre de l'annonce officielle disponible ici : http://www.postgresql.org/about/news/1456/

Le groupe de développement de PostgreSQL sort une mise à jour de sécurité pour toutes les versions stables du SGBD PostgreSQL. Cela inclut les versions 9.2.4, 9.1.9, 9.0.13 et 8.4.17. Cette mise à jour corrige une faille de sécurité très critique dans les versions 9.0 et supérieures. Il est fortement recommandé à tous les utilisateurs des versions concernées d'appliquer la mise à jour immédiatement.

La faille de sécurité corrigée dans cette version a la dénomination CVE-2013-1899. Elle permettait à une requête de connexion contenant un nom de base de données commençant par ”-” d'être utilisé afin d'endommager ou de détruire des fichiers dans le répertoire de données du serveur. Quiconque ayant accès au port d'écoute de PostgreSQL peut initier une telle requête. Cette faille a été découverte par Mitsumasa Kondo et Kyotaro Horiguchi du NTT Open Source Software Center.

Deux autres correctifs de failles de sécurité moins importantes sont également inclus dans cette version: CVE-2013-1900, où un nombre généré aléatoirement par les fonctions du module contrib pgcrypto pouvait être facile à deviner par un autre utilisateur de la base de données, et CVE-2013-1901, qui permet à tort à un utilisateur non autorisé de lancer des commandes qui peuvent interférer avec une sauvegarde en cours. Finalement, cette version résout également deux problèmes de sécurité pour les installeurs graphiques pour Linux et Mac OS X : transmission non sécurisée des mots de passe super utilisateur à un script (CVE-2013-1903) et utilisation de noms de fichiers prévisibles dans /tmp (CVE-2013-1902). Marko Kreen, Noah Misch et Stegan Kaltenbrunner ont respectivement rapportés ces failles.

Nous sommes reconnaissants des efforts de chacun des développeurs pour rendre PostgreSQL plus sûr. Cette mise à jour corrige également plusieurs erreurs dans la gestion des index GiST. Après la mise à jour, il est conseillé d'utiliser un REINDEX sur chacun des index GiST qui correspondent à un des problèmes reportés ci-dessous.

Cette mise à jour contient également des correctifs à plusieurs problèmes mineurs découverts et corrigés par la communauté PostgreSQL durant les deux derniers mois, dont :

  • Corriger les index GiST pour qu'ils n'utilisent plus de comparaisons géométriques «floues» pour des colonnes de type box, polygon, circle et point.
  • Corriger un problème dans le module contrib btree_gist sur les index GiST pour des colonnes de type text, bytea et numeric.
  • Corriger un bug dans le code de séparation pour les index GiST multi-colonnes.
  • Corriger une fuite tampon dans le rejeu des WAL causant des erreurs « incorrect local pin count ».
  • S'assurer d'effectuer la restauration après un arrêt brutal avant d'entrer en restauration d'archive après un arrêt brutal lorsque le fichier recovery.conf est présent.
  • Éviter de supprimer les WAL non encore archivés lors d'une restauration après arrêt brutal.
  • Corriger un problème de séquencement critique (race condition) lors d'un DELETE RETURNING.
  • Corriger un crash possible du planificateur après l'ajout de colonnes à une vue dépendant d'une autre vue.
  • Éliminer une fuite mémoire dans la fonction spi_prepare() de PL/Perl.
  • Corriger pg_dumpall pour gérer correctement un nom de base de données contenant « = ».
  • Éviter un crash de pg_dump lorsqu'une chaîne de connexion incorrecte est utilisée.
  • Ignorer les index invalides dans pg_dump et pg_upgrade.
  • Inclure uniquement le sous-répertoire de la version courante du serveur lors d'une sauvegarde d'un tablespace avec pg_basebackup.
  • Ajouter une vérification de version de serveur dans les outils pg_basebackup et pg_receivexlog.
  • Corriger le module contrib dblink pour gérer de manière sécurisée des valeurs incohérentes des paramètres DateStyle ou IntervalStyle.
  • Corriger la fonction similarity() du module contrib pg_trgm pour retourner zéro pour les chaînes de moins d'un trigramme.
  • Permettre la compilation de PostgreSQL avec Microsoft Visual Studio 2012.
  • Mettre à jour les fichiers de données de fuseaux horaires pour les modifications de changements d'heure au Chili, Haïti, Maroc, Paraguay et quelques zones russes.

Comme avec les autres versions mineures, les utilisateurs n'ont besoin ni de sauvegarder et recharger leur instance, ni d'utiliser pg_upgrade pour appliquer cette mise à jour. Vous devez simplement arrêter PostgreSQL et mettre à jour les binaires. Les utilisateurs qui n'ont pas effectuées les mises à jour précédentes peuvent avoir quelques étapes supplémentaires. Les détails sont disponibles dans les notes de version (Release Notes). Pour cette version, il est aussi conseillé de reconstruire (REINDEX) les index de type GIST qui pourraient exister sur les bases.

Téléchargez les nouvelles versions maintenant sur : http://www.postgresql.org/download/

par daamien le jeudi 4 avril 2013 à 20h56

mercredi 3 avril 2013

Christophe Chauvet

Utiliser le dépôt Debian/Ubuntu de PostgreSQL.org

Le projet PostgreSQL possède depuis peu son propre dépôt APT pour les différentes versions des serveurs encore maintenu et PgAdmin3, sur les versions de Debian et Ubuntu suivantes

  • Debian
    • Etch
    • Lenny
    • Squeeze
    • Wheezy
    • Sid
  • Ubuntu
    • Precise (12.04)

Si vous utilisiez déjà le dépôt squeeze backports par exemple, vous pouvez basculer facilement vers ce nouveau dépôt sans problème

Clé de signature des paquets

Avant d'installer une version de PostgreSQL, il faut ajouter la clé d'authentification des paquets dans notre trousseau de clé.

wget -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -

source.list

Il faut ensuite ajouter le dépôt au source.list, pour cela créer le fichier /etc/apt/sources.list.d/pgdg.list et ajouter les lignes suivantes (l'exemple ci-dessous est pour la version squeeze).

deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main

Remplacer Squeeze par le nom de votre distribution.

Préférences

Pour indiquer à votre distribution de prendre et mettre à jour votre ou vos PostgreSQL à partir de cette source, il faut rajouter une configuration dite de pinning

Créer le fichier /etc/apt/preferences.d/pgdg.pref et ajouter les lignes suivantes

Package: *
Pin: release o=apt.postgresql.org
Pin-Priority: 500

Initialisation

Une fois la configuration, il faut faire un update pour mettre a jour votre gestionnaire de paquet avec ce nouveau dépôt, et charger le trousseau de clé

apt-get update
apt-get install pgdg-keyring

Ensuite il en reste plus qu'a installer la version de PostgreSQL que vous souhaitez.

apt-get install postgresql-9.2 postgresql-client-9.2 postgresql-contrib-9.2 postgresql-plpython-9.2 postgresql-server-dev-9.2 libpq-dev

par Christophe Chauvet le mercredi 3 avril 2013 à 06h05

mardi 2 avril 2013

Actualités PostgreSQL.fr

Mise à jour importante à prévoir le 4 avril !

Le jeudi 4 avril 2013, le groupe de développement de PostgreSQL annoncera une mise à jour de sécurité pour toutes les versions de PostgreSQL. Ce correctif corrigera une vulnérabilité majeure. Tous les administrateurs de PostgreSQL devront dès lors mettre à jour leur système le plus rapidement possible.

Les détails de la vulnérabilité ne sont pas publiés mais tout indique qu'il s'agit d'un problème très sérieux.

Cette pré-annonce est diffusée en avance pour que les mesures adéquates soient prises afin que les mises à jour soit effectuées rapidement après la sortie de l'annonce officielle le 4 avril.

Comme toujours, les mises à jours de sécurité se font très simplement en installant les nouveaux paquets et en relançant le serveur. Il n'est pas nécessaire de faire un dump/restore, ni d'utiliser pg_upgrade.

Voir l'annonce officielle : http://www.postgresql.org/about/news/1454/

par daamien le mardi 2 avril 2013 à 08h03

vendredi 29 mars 2013

Dimitri Fontaine

The Need For Speed

Hier se tenait la cinquième édition de la conférence organisée par dalibo, où des intervenants extérieurs sont régulièrement invités. Le thème hier était à la fois clair et très vaste : la performance.

J'ai eu le plaisir de réaliser une présentation intitulée « The Need for Speed » dans laquelle on replace l'effort d'optimisation dans son contexte métier, afin de faire une étude des coûts et bénéfices et de savoir non seulement à quoi s'attendre mais aussi quand s'arrêter.

Merci à dalibo pour cette conférence !

par dim@tapoueh.org (Dimitri Fontaine) le vendredi 29 mars 2013 à 08h49

dimanche 17 mars 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 10 mars 2013

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

  • Le PyPgDay aura lieu le 13 mars au Santa Clara Convention Center, le premier jour de la PyCon. Informations par là : http://wiki.postgresql.org/wiki/PyPgDay2013
  • Le PGDay 2013 de New-York City aura lieu le 22 mars : http://pgday.nycpug.org/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. La date limite pour les propositions de conférence est le samedi 24 mars 2013 à 23h59 CEST : http://pgday.fr/call_for_papers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • L'appel à conférenciers pour PostgreSQL Brazil, événement tenu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil, est lancé. Les propositions sont attendues jusqu'au 15 mars : http://pgbr.postgresql.org.br/2013/chamada.en.php

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

Magnus Hagander a poussé :

Tom Lane a poussé :

  • Fix overflow check in tm2timestamp (this time for sure). I fixed this code back in commit 841b4a2d5, but didn't think carefully enough about the behavior near zero, which meant it improperly rejected 1999-12-31 24:00:00. Per report from Magnus Hagander. http://git.postgresql.org/pg/commitdiff/542eeba26992305d872be699158cb3ab1c2be6e6
  • Fix to_char() to use ASCII-only case-folding rules where appropriate. formatting.c used locale-dependent case folding rules in some code paths where the result isn't supposed to be locale-dependent, for example to_char(timestamp, 'DAY'). Since the source data is always just ASCII in these cases, that usually didn't matter ... but it does matter in Turkish locales, which have unusual treatment of "i" and "I". To confuse matters even more, the misbehavior was only visible in UTF8 encoding, because in single-byte encodings we used pg_toupper/pg_tolower which don't have locale-specific behavior for ASCII characters. Fix by providing intentionally ASCII-only case-folding functions and using these where appropriate. Per bug #7913 from Adnan Dursun. Back-patch to all active branches, since it's been like this for a long time. http://git.postgresql.org/pg/commitdiff/80b011ef0a13bb326861f79ba987b4fa04ae4a27
  • Fix missing #include in commands/matview.h. It needs parsenodes.h to be compilable regardless of previous headers. http://git.postgresql.org/pg/commitdiff/e11cb8ba2c9134c9f16253213f2f0cf089c5838e
  • Arrange to cache FdwRoutine structs in foreign tables' relcache entries. This saves several catalog lookups per reference. It's not all that exciting right now, because we'd managed to minimize the number of places that need to fetch the data; but the upcoming writable-foreign-tables patch needs this info in a lot more places. http://git.postgresql.org/pg/commitdiff/1908abc4a37d397356c9cdf0fd31c33a86281d63
  • Fix infinite-loop risk in fixempties() stage of regex compilation. The previous coding of this function could get into situations where it would never terminate, because successive passes would re-add EMPTY arcs that had been removed by the previous pass. Rewrite the function completely using a new algorithm that is guaranteed to terminate, and also seems to be usually faster than the old one. Per Tcl bugs 3604074 and 3606683. Tom Lane and Don Porter http://git.postgresql.org/pg/commitdiff/a7b61d4f5af37344f8973b2dfce47e2ba2680061
  • Support writable foreign tables. This patch adds the core-system infrastructure needed to support updates on foreign tables, and extends contrib/postgres_fdw to allow updates against remote Postgres servers. There's still a great deal of room for improvement in optimization of remote updates, but at least there's basic functionality there now. KaiGai Kohei, reviewed by Alexander Korotkov and Laurenz Albe, and rather heavily revised by Tom Lane. http://git.postgresql.org/pg/commitdiff/21734d2fb896e0ecdddd3251caa72a3576e2d415
  • Band-aid for regression test expected-results problem with timestamptz. We probably need to tell the remote server to use specific timezone and datestyle settings, and maybe other things. But for now let's just hack the postgres_fdw regression test to not provoke failures when run in non-EST5EDT environments. Per buildfarm. http://git.postgresql.org/pg/commitdiff/f7951eef89be78c50ea2241f593d76dfefe176c9

Kevin Grittner a poussé :

Andrew Dunstan a poussé :

Peter Eisentraut a poussé :

Robert Haas a poussé :

Heikki Linnakangas a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Alvaro Herrera sent in three more revisions of a patch to handle sql_drop in event triggers.
  • Michael Paquier sent in nine more revisions of a patch to add REINDEX CONCURRENTLY.
  • Joachim Wieland sent in another revision of a patch to implement parallel pg_dump.
  • Peter Eisentraut sent in another revision of a patch to implement an idempotent option for pg_dump.
  • Heikki Linnakangas sent in another revision of a patch to optimize pglz.
  • Kyotaro HORIGUCHI sent in another revision of a patch to fix the width specifier in format().
  • Heikki Linnakangas and Amit Kapila traded patches to improve WAL performance by reducing the amount of same written in updates.
  • Amit Kapila sent in another revision of a patch to enable changing postgresql.conf parameters via SQL.
  • Laurenz Albe sent in another revision of a patch to clarify some of the documentation on floating point.
  • Ian Barwick sent in a patch to clarify the CREATE TRIGGER documentation.
  • Jeff Davis and Greg Smith traded patches to enable page checksums.
  • Robins sent in a patch to add a simple test of psql to "make check".

par N Bougain le dimanche 17 mars 2013 à 15h05

mardi 12 mars 2013

Damien Clochard

PG Day France 2013 : Encore quelques jours pour soumettre vos propositions

Cette année encore la communauté francophone de PostgreSQL se réunira pour le PG Day France qui se tiendra à Nantes le 13 juin 2013.

L'occasion parfaite pour présenter une étude de cas, un projet en cours de développement ou une fonctionnalité de PostgreSQL !

L'appel à orateurs se terminera dans quelques jours, d'ici là n'hésitez pas à proposer une intervention !

http://pgday.fr/pgday2013:appel_a_orateurs

par damien le mardi 12 mars 2013 à 22h08

samedi 9 mars 2013

Philippe Beaudoin

1 500 milliards de requêtes SQL !

Mon activité professionnelle chez Bull m'amène à travailler très régulièrement avec la CNAF (Caisse Nationale d'Allocations Familiales).
En 2008-2009, j'ai eu la joie de participer activement à la mise en place de PostgreSQL pour une application éminemment critique, celle qui supporte le cœur du métier des CAF : le calcul et le paiement des prestations sociales.
Cette semaine, j'ai pu compiler diverses statistiques techniques. Quelques règles de 3 plus tard, j'en suis arrivé à la conclusion que nous venions tout juste de franchir la barre symbolique des :
1 500 milliards de requêtes SQL exécutées !
et ceci sans que le SGBD ne soit jamais pris en défaut.
Quelqu'un doutait-il de la robustesse de PostgreSQL ?

par philippe beaudoin le samedi 9 mars 2013 à 16h26

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 3 mars 2013

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

  • Le PyPgDay aura lieu le 13 mars au Santa Clara Convention Center, le premier jour de la PyCon. Informations par là : http://wiki.postgresql.org/wiki/PyPgDay2013
  • Le PGDay 2013 de New-York City aura lieu le 22 mars : http://pgday.nycpug.org/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. La date limite pour les propositions de conférence est le samedi 24 mars 2013 à 23h59 CEST : http://pgday.fr/call_for_papers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/
  • L'appel à conférenciers pour PostgreSQL Brazil, événement tenu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil, est lancé. Les propositions sont attendues jusqu'au 15 mars : http://pgbr.postgresql.org.br/2013/chamada.en.php

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

Andrew Dunstan a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Install headers from the new src/include/common subdirectory. This got missed in commit 8396447cdbdff0b62914748de2fec04281dc9114. Andres Freund http://git.postgresql.org/pg/commitdiff/c153530dc10bf5ff6dc5a89249f9cb596dd71a63
  • Clean up "stopgap" implementation of timestamptz_to_str(). Use correct type for "result", fix bogus strftime argument, don't use unnecessary static variables, improve comments. Andres Freund and Tom Lane http://git.postgresql.org/pg/commitdiff/1418e6e07b69766ea1e231917601f18fcf0c2624
  • Add missing .gitignore file. http://git.postgresql.org/pg/commitdiff/08f9728057a485edf5b3a589e70548e1f0da4e53
  • Add missing error check in regexp parser. parseqatom() failed to check for an error return (NULL result) from its recursive call to parsebranch(), and in consequence could crash with a null-pointer dereference after an error return. This bug has been there since day one, but wasn't noticed before, probably because most error cases in parsebranch() didn't actually lead to returning NULL. Add the missing error check, and also tweak parsebranch() to exit in a less indirect fashion after a call to parseqatom() fails. Report by Tomasz Karlik, fix by me. http://git.postgresql.org/pg/commitdiff/73dc003beef859e0b67da463c5e28f5468d3f17f
  • Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane http://git.postgresql.org/pg/commitdiff/a4d3a504e730c47ccee5082ee703082e42c8b5ce
  • Fix SQL function execution to be safe with long-lived FmgrInfos. fmgr_sql had been designed on the assumption that the FmgrInfo it's called with has only query lifespan. This is demonstrably unsafe in connection with range types, as shown in bug #7881 from Andrew Gierth. Fix things so that we re-generate the function's cache data if the (sub)transaction it was made in is no longer active. Back-patch to 9.2. This might be needed further back, but it's not clear whether the case can realistically arise without range types, so for now I'll desist from back-patching further. http://git.postgresql.org/pg/commitdiff/2b78d101d1d6b1d8533a7b7aeff4d82b10a915f8
  • Get rid of any toast table when converting a table to a view. Also make sure other fields of the view's pg_class entry are appropriate for a view; it shouldn't have relfrozenxid set for instance. This ancient omission isn't believed to have any serious consequences in versions 8.4-9.2, so no backpatch. But let's fix it before it does bite us in some serious way. It's just luck that the case doesn't cause problems for autovacuum. (It did cause problems in 8.3, but that's out of support.) Andres Freund http://git.postgresql.org/pg/commitdiff/b15a6da29217b14f02895af1d9271e84415a91ae
  • Fix map_sql_value_to_xml_value() to treat domains like their base types. This was already the case for domains over arrays, but not for domains over certain built-in types such as boolean. The special formatting rules for those types should apply to domains over them as well. Per discussion. While this is a bug fix, it's also a behavioral change that seems likely to trip up some applications. So no back-patch. Pavel Stehule http://git.postgresql.org/pg/commitdiff/bc61878682051678ade5f59da7bfd90ab72ce13b

Alvaro Herrera a poussé :

Kevin Grittner a poussé :

  • Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending. http://git.postgresql.org/pg/commitdiff/3bf3ab8c563699138be02f9dc305b7b77a724307
  • Remove accidentally-committed .orig file. http://git.postgresql.org/pg/commitdiff/d63977eea3ab18fdec05e370b633d10b9fd20179

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Greg Smith sent in two more revisions of a patch to add page checksums.
  • Andres Freund sent in an RfC patch to extend namespace of valid GUC names.
  • Andrew Dunstan sent in another revision of a patch to enhance JSON generation.
  • Ivan Lezhov sent in another revision of a patch to clarify the documentation on custom format pg_dump backups.
  • Jonathan Rogers sent in another revision of a patch to allow using filesystem-level cloning to speed up operations like CREATE DATABASE.
  • Kyotaro HORIGUCHI and Pavel Stehule traded patches to enhance the format function.
  • Michael Paquier sent in another revision of a patch to add REINDEX CONCURRENTLY.
  • Zoltan Boszormenyi sent in another revision of a patch to fix lock_timeout on Windows.
  • Alexander Korotkov sent in another revision of a patch to improve selectivity for ranges in GIN.
  • Heikki Linnakangas sent in a patch to help make the LZ compressor work faster.
  • Alvaro Herrera sent in another revision of a patch to support dropped objects in event triggers.
  • Heikki Linnakangas sent in a patch to make the scanner and parser more efficient by adding some flex states to help with the UESCAPE cases.
  • Satoshi Nagayasu sent in another revision of a patch to fix pgstattuple/pgstatindex to use regclass-type as the argument.
  • Laurenz Albe sent in a documentation patch to clarify the use of floating point.
  • Greg Smith sent in another revision of a patch to catch a buffer assertion issue under certain pgbench loads.

par N Bougain le samedi 9 mars 2013 à 02h12

Nouvelles hebdomadaires de PostgreSQL - 24 février 2013

L'appel à conférenciers pour PostgreSQL Brazil, événement tenu du 15 au 17 août 2013 à Porto Velho, État du Rondônia au Brésil, est lancé. Les propositions sont attendues jusqu'au 15 mars : http://pgbr.postgresql.org.br/2013/chamada.en.php

Le programme du PGCon, la conférence mondiale des développeurs PostgreSQL, est en ligne : http://www.pgcon.org/2013/schedule/events.en.html?pgannounce

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en février

PostgreSQL Local

  • Le PyPgDay aura lieu le 13 mars au Santa Clara Convention Center, le premier jour de la PyCon. Informations par là : http://wiki.postgresql.org/wiki/PyPgDay2013
  • Le PGDay 2013 de New-York City aura lieu le 22 mars : http://pgday.nycpug.org/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. La date limite pour les propositions de conférence est le samedi 24 mars 2013 à 23h59 CEST : http://pgday.fr/call_for_papers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/

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

Peter Eisentraut a poussé :

Alvaro Herrera a poussé :

Heikki Linnakangas a poussé :

  • Fix yet another typo in comment. Etsuro Fujita http://git.postgresql.org/pg/commitdiff/5d6899dbae7ac19d90f135e2ad64832e4ca8d064
  • Don't pass NULL to fprintf, if a bogus connection string is given to pg_dump. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/2930c05634bcb7491bc443a493405e927ed08443
  • Fix pg_dumpall with database names containing =. If a database name contained a '=' character, pg_dumpall failed. The problem was in the way pg_dumpall passes the database name to pg_dump on the command line. If it contained a '=' character, pg_dump would interpret it as a libpq connection string instead of a plain database name. To fix, pass the database name to pg_dump as a connection string, "dbname=foo", with the database name escaped if necessary. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/f435cd1d385859a0cdb1d70fccc21dde2b1ee116
  • Fix thinko in previous commit. We must still initialize minRecoveryPoint if we start straight with archive recovery, e.g when recovering from a normal base backup taken with pg_start/stop_backup. Otherwise we never consider the system consistent. http://git.postgresql.org/pg/commitdiff/6c4f6664b201bea77eb6e3f813559e3911a5ef35
  • If recovery.conf is created after "pg_ctl stop -m i", do crash recovery. If you create a base backup using an atomic filesystem snapshot, and try to perform PITR starting from that base backup, or if you just kill a master server and create recovery.conf to put it into standby mode, we don't know how far we need to recover before reaching consistency. Normally in crash recovery, we replay all the WAL present in pg_xlog, and assume that we're consistent after that. And normally in archive recovery, minRecoveryPoint, backupEndRequired, or backupEndPoint is set in the control file, indicating how far we need to replay to reach consistency. But if the server was previously up and running normally, and you kill -9 it or take an atomic filesystem snapshot, none of those fields are set in the control file. The solution is to perform crash recovery first, replaying all the WAL in pg_xlog. After that's done, we assume that the system is consistent like in normal crash recovery, and switch to archive recovery mode after that. Per report from Kyotaro HORIGUCHI. In his scenario, recovery.conf was created after "pg_ctl stop -m i". I'm not sure we need to support that exact scenario, but we should support backing up using a filesystem snapshot, which looks identical. This issue goes back to at least 9.0, where hot standby was introduced and we started to track when consistency is reached. In 9.1 and 9.2, we would open up for hot standby too early, and queries could briefly see an inconsistent state. But 9.2 made it more visible, as we started to PANIC if we see a reference to a non-existing page during recovery, if we've already reached consistency. This is a fairly big patch, so back-patch to 9.2 only, where the issue is more visible. We can consider back-patching further after this has received some more testing in 9.2 and master. http://git.postgresql.org/pg/commitdiff/abf5c5c9a4f142b3343614746bb9e99a794f8e7b

Tom Lane a poussé :

Andrew Dunstan a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Zoltan Boszormenyi sent in a pair of patches to fix a pair of bugs: one where recovery.conf was generated without double-escaping quoted values, and another in parsing the connection string in libpq when the parameter value starts with a single-quote character.
  • Gurjeet Singh sent in a patch to make pgindent work cleanly.
  • Gurjeet Singh sent in a patch which adds a one-line comment to improve understanding of the VARSIZE_ANY_EXHDR macro.
  • Kevin Grittner sent in two revisions of a patch to add a pg_matviews catalog view.
  • Alexander Law sent in a patch to fix an issue where postmaster messages were unreadable in a Windows console.
  • Andres Freund sent in a patch to fix up the conversion of a relation to a view for TOAST, etc.
  • Amit Kapila and Heikki Linnakangas traded patches to add PQconninfoParseParams and PQconninfodefaultsMerge to libpq.
  • Etsuro Fujita sent in another revision of a patch to add hooks for pre- and post-processor executables for COPY and \copy.
  • Alvaro Herrera sent in another revision of a patch to add an event trigger on DDL DROP.
  • Michael Paquier sent in two more revisions of a patch to add REINDEX CONCURRENTLY.
  • Pavel Stehule sent in another revision of a patch to unify the serializations of booleans and domains over same in XML.
  • Dimitri Fontaine sent in another revision of a patch to add Extension Templates.
  • Zoltan Boszormenyi sent in another revision of a patch to fix a lock timeout issue.

par N Bougain le samedi 9 mars 2013 à 01h56

jeudi 7 mars 2013

Actualités PostgreSQL.fr

Appel à Orateurs : PG Day France le 13 juin 2013 à Nantes

Le PG Day France est la conférence annuelle de la communauté francophone de PostgreSQL. Cette année, l’événement se tiendra le jeudi 13 juin à Nantes. Une centaine de visiteurs sont attendus pour une journée d'échanges autour de PostgreSQL et de ses projets associés.

Retrouvez plus d'informations sur le site de l’événement : http://www.pgday.fr

Vous êtes expert sur un domaine lié aux bases de données libres ? Vous avez utilisé PostgreSQL dans un contexte spécifique (gros volumes, forte charge, client reconnu, projet innovant, etc.) ? Vous participez à un projet libre lié à PostgreSQL ? Alors n'hésitez pas à proposer une présentation !

Pour l’édition 2013, les thèmes particulièrement mis en lumière seront les suivants :

  • Administration de bases volumineuses
  • Études de cas / témoignages
  • Industrialisation (tests, benchmarks, matériel, déploiements, etc.)
  • Entrepôts de données et systèmes décisionnels
  • Travaux sur la sémantique
  • Big Data
  • Data Mining / Exploration de Données
  • Systèmes d'Information Géographiques

Cette liste n'est pas exhaustive. Il est possible de proposer d'autres sujets liés à PostgreSQL.

La conférence PG Day France est à destination de professionnels, notamment les directeurs informatiques, les décideurs, les chefs de projets, les administrateurs de bases de données, les développeurs, les administrateurs systèmes et tous les profils qui entrent en contact avec un SGBD.

Pour soumettre une intervention, il vous suffit d'envoyer un e-mail à l'adresse contact@pgday.fr, en précisant les éléments suivants :

  • Votre nom et prénom;
  • Votre société / employeur;
  • Votre compte twitter (optionnel);
  • Le titre de votre intervention;
  • La durée de votre intervention (45 minutes max. questions comprises);
  • Une description courte (200 caractères max.);
  • Une description longue (700 caractères max.);
  • Une photo (200x200 pixels minimum).

Les interventions devront être en français et disponibles sous licence libre. Les interventions pourront faire l'objet d'une captation audio/vidéo et d'une diffusion sur internet.

La date limite de réception des propositions est le 24 mars 2013 à 23h59 CEST.

Dans le courant du mois de mars 2013, un sondage communautaire sera organisé au sein de la communauté francophone pour évaluer les différentes propositions.

Ensuite, le comité de sélection étudiera toutes les propositions valides. Le choix des sessions sera basé sur la présentation de la soumission, son intérêt pour une audience professionnelle, la cohérence du programme de la journée et sur le résultat du vote préliminaire. La décision du comité de sélection sera finale et sans appel.

Le comité de programme est composé des personnes suivantes :

  • Gautier Di Folco (Étudiant, INSA Lyon)
  • Vincent Picavet (Co-fondateur, Oslandia)
  • Christophe Chauvet (Directeur Technique, Sylëam Info Services)
  • Sébastien Lardière (DBA, Hi-Media)
  • Thomas Reiss (DBA, dalibo)
  • Ludovic Levesque (CTO, Fotolia)

Les membres du comité s'expriment en leur nom propre. Leurs choix ne reflètent pas la position de leur employeur.

Les orateurs sélectionnés seront avertis par e-mail avant le 15 avril 2013, jour de l'annonce du programme.

Pour toute question à propos de cet appel à conférenciers et du PG Day France en général, vous pouvez envoyer un message à l'adresse : pgdayfr@listes.postgresql.fr

par daamien le jeudi 7 mars 2013 à 09h50

lundi 25 février 2013

Thomas Reiss

Les bases de données relationnelles avec PHP

L'AFUP organise une soirée intitulée les bases de données relationnelles avec PHP. Je viendrai présenter PostgreSQL, son développement et sa communauté, ses principales fonctionnalités et quelques retours d'expérience.

Si vous ne connaissez pas PostgreSQL, c'est le moment de venir le découvrir à cette occasion, près de la Défense, à Paris.

Pour vous inscrire, ça se passe ici :

par Thomas Reiss le lundi 25 février 2013 à 19h01

dimanche 24 février 2013

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 17 février 2013

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en février

PostgreSQL Local

  • Le PyPgDay aura lieu le 13 mars au Santa Clara Convention Center, le premier jour de la PyCon. Informations par là : http://wiki.postgresql.org/wiki/PyPgDay2013
  • Le PGDay 2013 de New-York City aura lieu le 22 mars : http://pgday.nycpug.org/
  • Le PgDay Fr est l'événement majeur de la communauté francophone. La date limite pour les propositions de conférence est le samedi 24 mars 2013 à 23h59 CEST : http://pgday.fr/call_for_papers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa : http://www.pgcon.org/2013/
  • La 6ème conférence annuelle "Prague PostgreSQL Developers Day", organisée par le CSPUG (Groupe des utilisateurs tchèques et slovaques de PostgreSQL), aura lieu le 30 mai 2013 à la Faculté des Sciences Mathématiques & Physiques de l'Université Charles (Malostranske namesti 25, Prague). Les candidatures des conférenciers sont attendues jusqu'au 14 avril à l'adresse <info AT p2d2 POINT cz>. D'avantage d'informations sur le site : http://www.p2d2.cz/

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

  • Fix checkpoint after fast promotion. The intention was to request a regular online checkpoint immediately after end of recovery, when performing "fast promotion". However, because the checkpoint was requested before other backends were allowed to write WAL, the checkpointer process performed a restartpoint rather than a checkpoint. Delay the RequestCheckPoint call until after recovery has truly ended, so that you get a real checkpoint. http://git.postgresql.org/pg/commitdiff/b669f416cee77ef9025b80f9c4201688578447d1
  • Support unlogged GiST index. The reason this wasn't supported before was that GiST indexes need an increasing sequence to detect concurrent page-splits. In a regular WAL- logged GiST index, the LSN of the page-split record is used for that purpose, and in a temporary index, we can get away with a backend-local counter. Neither of those methods works for an unlogged relation. To provide such an increasing sequence of numbers, create a "fake LSN" counter that is saved and restored across shutdowns. On recovery, unlogged relations are blown away, so the counter doesn't need to survive that either. Jeevan Chalke, based on discussions with Robert Haas, Tom Lane and me. http://git.postgresql.org/pg/commitdiff/62401db45c4feff9be296fa78a8bb7b9947d69de
  • Update visibility map in the second phase of vacuum. There's a high chance that a page becomes all-visible when the second phase of vacuum removes all the dead tuples on it, so it makes sense to check for that. Otherwise the visibility map won't get updated until the next vacuum. Pavan Deolasee, reviewed by Jeff Janes. http://git.postgresql.org/pg/commitdiff/fdf9e21196a6f58c6021c967dc5776a16190f295
  • Don't delete unarchived WAL files during crash recovery. Bug reported by Jehan-Guillaume (ioguix) de Rorthais. This was introduced with the change to keep WAL files restored from archive in pg_xlog, in 9.2. http://git.postgresql.org/pg/commitdiff/c9cc7e05c6d82a9781883a016c70d95aa4923122
  • Force archive_status of .done for xlogs created by dearchival/replication. This is a forward-patch of commit 6f4b8a4f4f7a2d683ff79ab59d3693714b965e3d, applied to 9.2 back in August. The plan was to do something else in master, but it looks like it's not going to happen, so let's just apply the 9.2 solution to master as well. Fujii Masao http://git.postgresql.org/pg/commitdiff/c2f79ba2691a4863db53003f25538f8806ebd2db
  • Better fix for "unarchived WAL files get deleted on crash recovery" bug. Revert my earlier fix for the bug that unarchived WAL files get deleted on crash recovery, commit c9cc7e05c6d82a9781883a016c70d95aa4923122. We create a .done file for files streamed or restored from archive, so the WAL file recycling logic used during normal operation works just as well during archive recovery. Per Fujii Masao's suggestion. http://git.postgresql.org/pg/commitdiff/1bd42cd70abdbc946ad64c3c8eaefed4bb8b1145
  • Include previous TLI in end-of-recovery and shutdown checkpoint records. This isn't used for anything but a sanity check at the moment, but it could be highly valuable for debugging purposes. It could also be used to recreate timeline history by traversing WAL, which seems useful. http://git.postgresql.org/pg/commitdiff/7803e9327db3788f68d820c19f4081afb79edd12

Peter Eisentraut a poussé :

Alvaro Herrera a poussé :

  • Don't build libpgcommon_srv.a just yet. It's empty, and some archivers do not support that case. http://git.postgresql.org/pg/commitdiff/0f980b0e17d95e77dc2822eb7855d072a5874d9a
  • Rename "string" pstrdup argument to "in". The former name collides with a symbol also used in the isolation test's parser, causing assorted failures in certain platforms. http://git.postgresql.org/pg/commitdiff/0e81ddde2c62ada7f818114ca961d80d42370e32
  • Create libpgcommon, and move pg_malloc et al to it. libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro. http://git.postgresql.org/pg/commitdiff/8396447cdbdff0b62914748de2fec04281dc9114

Tom Lane a poussé :

  • Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro Herrera. http://git.postgresql.org/pg/commitdiff/8396447cdbdff0b62914748de2fec04281dc9114
  • Fix contrib/pg_trgm's similarity() function for trigram-free strings. Cases such as similarity('', '') produced a NaN result due to computing 0/0. Per discussion, make it return zero instead. This appears to be the basic cause of bug #7867 from Michele Baravalle, although it remains unclear why her installation doesn't think Cyrillic letters are letters. Back-patch to all active branches. http://git.postgresql.org/pg/commitdiff/9728eda7925b6d42621b38c48e91ef9ab8d90cbc
  • Fix CVE-2013-0255 properly. Revert commit ab0f7b6089fd215f6ce6081e2e222c38d643a526 (in HEAD only) in favor of the proper solution, which is to declare enum_recv() correctly in the system catalogs. It should be declared to take type "internal" not "cstring". Also improve the type_sanity regression test, which should have caught this typo, so that it actually would. Most of the relevant checks on the signature of type I/O functions should not have been restricted to basetypes/pseudotypes, as they should apply to any type's I/O functions. http://git.postgresql.org/pg/commitdiff/71627f3d1964ef9831ea7997d2f4ac5617c718cc
  • Invent pre-commit/pre-prepare/pre-subcommit events for xact callbacks. Currently it's only possible for loadable modules to get control during post-commit cleanup of a transaction. That doesn't work too well if they want to do something that could throw an error; for example, an FDW might need to issue a remote commit, which could well fail. To improve matters, extend the existing APIs for XactCallback and SubXactCallback functions to provide new pre-commit events for this purpose. The release notes will need to mention that existing callback functions should be checked to make sure they don't do something unwanted when one of the new event types occurs. In the examples within our source tree, contrib/sepgsql was fine but plpgsql had been a bit too cute. http://git.postgresql.org/pg/commitdiff/fdaf44862beba24c12434d31df556fab25fd3ee7

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Jeff Janes sent in a patch to bgbench which allows any arbitrary command to be executed upon the start up of each connection intended for benchmarking.
  • Andrew Dunstan sent in another revision of a patch to add a JSON API.
  • Manlio Perillo sent in a patch against libpq to send a Describe Portal message in PQsendPrepare.
  • Pavel Stehule and Dean Rasheed traded patches to fix the behavior of the width specifier in the format function in cases of mixed positional and ordered placeholders.
  • Michael Paquier sent in two more revisions of a patch to add REINDEX CONCURRENTLY.
  • Amit Kapila sent in another revision of a patch to implement identity projection.
  • Alvaro Herrera and Andres Freund traded patches to implement xlogdump.
  • Jonathan Rogers sent in a WIP patch to use BTRFS file cloning facilities to speed up CREATE DATABASE operations.
  • Amit Kapila sent in another revision of a patch to allow changing postgresql.conf settings via SQL.
  • David Fetter sent in two more revisions of a patch to add an optional FILTER clause to aggregates.
  • Alvaro Herrera and Tomas Vondra traded patches to split stats file per database.
  • Fujii Masao sent in another revision of a patch to prevent archiving restored WALs.
  • Bruce Momjian sent in a patch to go with subtle hints about mounting a PGDATA directories and similar at the root as opposed to a previous version that looked for filesystem-specific things like "lost+found".
  • Kevin Grittner sent in another revision of a patch to implement materialized views.
  • Andres Freund sent in an RfC patch to implement indirect TOAST support.
  • Pavel Stehule sent in another revision of a patch to implement function body checking for PL/pgsql.

par N Bougain le dimanche 24 février 2013 à 18h15

mardi 8 janvier 2013

Dimitri Fontaine (2nd Quadrant)

PostgreSQL 2013

Bonne Année 2013 à tous !

Le changement de calendrier civil est un moment privilégié pour faire le bilan de l’année passée et quelques prévisions pour l’année à venir. La rétrospective 2012 de PostgreSQL présente un très bon bilan, avec la mise à disposition de la version 9.2 dont l’adoption est en pleine croissance. Ce décalage entre la date de sortie d’une version et son adoption à grande échelle fait que 2012 est l’année où la version PostgreSQL 9.1 a été fortement déployée en production.

En ce qui concerne les conférences, nos experts ont profité de 2012 pour faire un petit tour du monde de PostgreSQL : nous avons en effet eu l’opportunité de présenter nos travaux en Belgique, au Canada, aux États Unis, en République Tchèque et plusieurs fois en France, à Lyon. Nous avons parlé des nouvelles fonctionnalités dont nous participons au développement (les Extensions, les Triggers étendus), les architectures que nous avons mises en place pour répondre à des besoins de Haute-Disponibilité, de Répartition de Charge, mais surtout de Durabilité des Données ; sans oublier bien sûr les aspects de mesures et améliorations des performances. Les contenus que nous avons utilisés lors de ces conférences sont bien sûr disponibles en ligne!

Ce tour du monde nous a permis de constater que PostgreSQL est de mieux en mieux équipé pour répondre à vos problématiques de garanties de données et de continuité des services, en particulier avec les version 9.1 et 9.2. Le circuit des conférences de la communauté PostgreSQL est un lieu d’échange très riche, où nous avons plaisir à rencontrer les utilisateurs et à écouter leur besoin, à prendre en compte leur point de vue pour les prochaines versions de votre moteur de base données préféré.

La prochaine conférence PostgreSQL organisée par la communauté Européenne de PostgreSQL se tient en belgique, à Bruxelles, le vendredi 1er février, en ouverture du FOSDEM. Je vous encourage fortement à vous y inscrire et à nous rejoindre!

Qu’attendre donc de 2013, après une telle année 2012 pour PostgreSQL ?

Suite à la circulaire de notre Premier Ministre, je pense que nous allons assister à un mouvement continu de migrations vers PostgreSQL, cette tendance me semble loin d’être arrivée en bout de course. L’arrivée sur le marché de solutions dites NoSQL se transforme doucement en « Not Only SQL », et PostgreSQL est prêt à s’intégrer dans des environnements de production hétérogènes complexes, en particulier avec ses Foreign Data Wrappers.

La période où l’on écrit sa lettre au père noël est bien évidemment terminée, mais si je pouvais émettre un voeux pour 2013… il concernerait la version de PostgreSQL qui sortira en 2014 et que nous allons commencer à préparer dès mars ou avril prochain. J’aimerais que cette version inclue une nouvelle approche plus simple et plus efficace pour résoudre le problème des tables à grands nombres de ligne, où la solution actuelle consister à créer des partitions de manière explicite. N’hésitez pas à nous contacter si vous partagez ce problème !

par Dimitri Fontaine le mardi 8 janvier 2013 à 11h05

jeudi 3 janvier 2013

Damien Clochard

Refonte de pgBadger en HTML5 : premier aperçu

PgBadger est un outil puissant pour optimiser vos serveurs PostgreSQL. À partir des fichiers log de vos serveurs, pgBadger va analyser le trafic SQL et produire une profusion de statistiques (les plus longues requêtes, le ratio lecture/écriture, etc.) Tout ceci est très utile, mais la quantité de données générée est si importante que les rapports générés par pgbadger sont difficiles à lire et que les stats utiles sont souvent noyées dans le flot ... Pour vous en convaincre, jetez un coup d'oeil sur cet exemple de rapport pgBadger  !

comme je le disais dans mon article précédent , nous avons travaillé dur pour redéfinir l'expérience utilisateur de pgBadger et créer un nouveau modèle de rapport.

Voici donc le premier aperçu du nouveau prototype (pour l'instant il s'agit simplement de code HTML statique, nous espérons présenter une démo interactive dans les prochaines semaines).

Comme vous pouvez le voir, nous avons suivi quelques principes de base:

  • Divisez les grosses tables HTML en petites tables et utiliser des onglets pour naviguer de l'une à l'autre:

pgbadger_proto_1.png

  • Laissez quelques espaces vides pour aérer et faciliter la lecture:

pgbadger_proto_2.png

  • Masquer les tableaux derrière les graphes, lorsque c'est possible:

pgbadger_proto_3.png

  • Mettre les infos détaillées dans des fenêtres popup que l'on peut masquer/afficher:

pgbadger_proto_4.png

  • Mettre l'accent sur les «valeurs clés» en jouant sur la taille des polices:

pgbadger_proto_5.png

Tout cela n'a rien d'extraordinaire et ce n'est pas très original... Mais ce nouveau design sera sûrement plus lisible et plus efficace. Nous espérons que cela va attirer de nouveaux utilisateurs et que cela sera apprécié par les utilisateurs existants.

Si vous avez des commentaires ou des idées, n'hésitez pas à rejoindre à la liste de discussion du projet pgBadger . Nous sommes à l'écoute !

par damien le jeudi 3 janvier 2013 à 22h06

mercredi 2 janvier 2013

Philippe Beaudoin

Introduction à E-Maj

Ce billet est le premier d'une série consacrée au projet open source E-Maj.

En deux mots, de quoi s'agit-il ?

E-Maj est une extension au SGBD PostgreSQL. Comme lui, il est disponible sous licence open source, en l’occurrence pour E-Maj la licence GPL.

Il permet d'enregistrer les mises à jour apportées à des tables relationnelles dans l'intention soit de les consulter soit de les annuler. La consultation permet par exemple d'analyser le comportement d'une application ou simplement d'avoir une trace des changements de contenu de tables. Quant à l'annulation des mises à jour, elle peut permettre de repositionner des tables dans un état prédéfini, en annulant l'effet d'un ou plusieurs traitements sur leur contenu.

Et je vous entends déjà dire. « Bon d'accord, il s'agit encore d'un outil de log de mises à jour. Mais il en existe déjà plusieurs dans le monde PostgreSQL. Alors pourquoi en inventer un autre ? ».

Effectivement, des contribs existent, tel que l'excellent table_log d'Andreas Scherbaum. Et le wiki de la communauté montre en détail comment se faire ses propres fonctions (wiki.postgresql.org/wiki/Audit_trig... et //wiki.postgresql.org/wiki/Audit_tr...)

Mais E-Maj présente deux grandes caractéristiques qui le rendent unique (du moins à ma connaissance !) : la manipulation d'ensembles de tables et la présence d'une interface graphique. Alors détaillons un peu ces deux aspects.

  1. Les « groupes de tables »

L'un des concepts sur lesquels E-Maj a été bâti est le « groupe de tables » (ou Tables Group en anglais). Il s'agit de mettre dans un même paquet, le « groupe de tables », toutes les tables qui vivent au même rythme, c'est à dire dont il faudra nécessairement, le cas échéant, annuler les mises à jour de manière cohérente. Par exemple, si j'ai une table des commandes et une tables des lignes de commande, il serait absurde de pouvoir annuler un ensemble de mises à jour sur l'une des tables sans annuler également les mises à jour de l'autre table. D'ailleurs la présence probable d'une clé étrangère (Foreign Key) entre ces deux tables nous rappellerait rapidement à l'ordre ! Avec E-Maj, le seul objet manipulable par l'utilisateur est le groupe de tables, et annuler les mises à jour d'une seule table est impossible (à moins bien sûr d'avoir un groupe de tables ne comprenant qu'une unique table).

  1. L'interface graphique

E-Maj comprend en fait deux grands composants :

  • une infrastructure installée dans chaque base de données cible, l'extension E-Maj proprement dite. Elle comprend quelques tables techniques et surtout un ensemble de fonctions permettant de réaliser en SQL toutes les opérations souhaitées,
  • une interface graphique sous la forme d'un plugin pour phpPgAdmin, l'outil web standard d'administration des bases PostgreSQL. Bien qu'optionnel, ce second composant facilite l'utilisation d'E-Maj, notamment pour les environnements de test,

Mais au fait, d'où vient ce nom étrange d'E-Maj ?

Il s'agit tout simplement de l'acronyme, en français, de « Enregistrement des Mises A Jour ». Oui, je sais, ce n'est pas très original. Mais il fallait trouver un nom. Et puis, prononcé à l'anglaise, cela ressemble au mot « image », E-Maj permettant en effet de reconstruire des sortes d'images de bases de données.

Nous aurons l'occasion de présenter plus en détail cette extension dans les prochains billets.

Une dernière information avant de vous quitter pour répondre aux impatients. Comment se procurer E-Maj ?

E-Maj est disponible sur pgfoundry, et sur le site des extensions PostgreSQL PGXN.org. Et toute la documentation, en français et en anglais, est bien sûr contenu dans le support.

Deux dépôts sur github sont aussi accessibles :

Le plugin phpPgAdmin n'est pas encore disponible en libre service (je vous dirai bientôt pourquoi). Mais il suffit de me le demander par email (phb point emaj at free point fr).

A suivre...

par philippe beaudoin le mercredi 2 janvier 2013 à 13h04

mardi 18 décembre 2012

Guillaume Lelarge

Use the index, luke! ... en français !

usetheindexluke.png

Il y a quelques mois de ça, j'ai découvert un site excellent grâce à un collègue (Marc Cousin pour ne pas le nommer). Ce site s'appelle Use the index, Luke! Ce site explique en des termes très simples ce que sont les index, comment une base de données les utilise, comment bien les concevoir pour avoir de meilleures performances, etc, etc. Le plus étonnant, c'est que les explications sont simples et limpides malgré des concepts assez complexes. Bref, j'ai dévoré le site complet en espérant en apprendre le plus possible. Son concepteur, Markus Winand, a fini par le publier sous la forme d'un livre. Je l'ai évidemment acheté pour pouvoir le relire entièrement tranquillement. J'ai fini par envoyer un mail à Markus pour lui demander s'il allait faire une version PDF. C'était bien le cas, j'ai même eu la possibilité de tester une version beta du PDF. Classe :)

En discutant avec Markus, on est tombé d'accord sur une traduction française. Puis pgconf.eu est arrivé (où j'ai d'ailleurs rencontré Markus), puis le boulot a repris... autant dire que le commencement du travail sur la traduction s'est trouvé fortement décalé. Mais j'ai enfin pu travailler dessus. Ça doit faire trois semaines que je travaille plus ou moins sérieusement dessus, et la moitié de la traduction est faite. Markus a décidé qu'il était possible de commencer à mettre ce début à disposition du monde entier (au moins :) ). C'est donc fait. C'est dispo sur http://use-the-index-luke.com/fr.

N'hésitez pas à m'indiquer tout problème de traduction ou de compréhension. Ce livre va évoluer, au moins le temps de sa traduction complète.

par Guillaume Lelarge le mardi 18 décembre 2012 à 21h39

mardi 13 novembre 2012

Damien Clochard

FOSDEM PGDay et Devroom 2013 - Annonce et Appel à Orateurs

Les personnes présentes à Prague pour pgconf.eu 2012 ont déjà eu la primeur de cette annonce. Voici quelques détails complémentaires.

Le PG Day du FOSDEM est une journée de conférence qui se tiendra juste avant le FOSDEM à Bruxelles le 1er février 2013. Il s'agit d'un événement dédié à PostgreSQL avec une session unique. Cette journée, proposée au tarif de 50€, se tiendra à l’hôtel Radisson Blu Royal au centre de Bruxelles. Les réservations sont obligatoires car le nombre de places est limité. Les réservations ne sont pas encore ouvertes mais cela ne saurait tarder.

Pour plus de détails sur la conférence et l’hôtel, rendez-vous sur : http://fosdem2013.pgconf.eu/

PostgreSQL Europe proposera également un "devroom" durant le FOSDEM le dimanche 3 février à l'Université Libre de Bruxelles (ULB). Cette journée reste gratuite, sans réservation et ouverte à tous les participants du FOSDEM.

Voir le site du FOSDEM pour tous les détails: https://fosdem.org/2013/

Un appel à orateurs vient d'être lancé pour **les deux** événements. PostgreSQL Europe recherche des intervenants pour chacune de ces journées, avec des présentations destinées aussi bien aux connaisseurs qu'aux débutants.

Plus d'info sur cet appel : http://fosdem2013.pgconf.eu/callforpapers/

La date limite est fixée au 21 décembre mais certaines interventions pourront être approuvées en avance, donc envoyez vos propositions rapidement !

PostgreSQL Europe a négocié des tarifs auprès de 2 hôtels différents à Bruxelles. Chacun de ces hôtels a un nombre de places limités, il est donc conseillé de réserver le plus tôt possible.

Rendez-vous sur: http://fosdem2013.pgconf.eu/venue/

PS: Ceci est une traduction libre du message original situé ici : http://archives.postgresql.org/pgsql-announce/2012-11/msg00005.php

par damien le mardi 13 novembre 2012 à 10h38

jeudi 1 novembre 2012

Guillaume Lelarge

Conférence à l'AFUP Lyon

Hier soir, je suis allé donner une conférence à l'AFUP de Lyon avec Dimitri. Le but était de faire une introduction à PostgreSQL auprès de développeurs PHP.

J'ai commencé à 19h30 avec une conférence pour une heure d'introduction à PostgreSQL. J'ai divisé cette conférence en plusieurs parties :

  • quelques informations globales sur PostgreSQL : son historique, ses fonctionnalités, sa communauté, ses sponsors, etc. ;
  • l'installation : avec des informations sur le matériel, sur le système d'exploitation, et sur les paquets précompilés pour PostgreSQL ;
  • la configuration, du système d'exploitation et de PostgreSQL ;
  • la maintenance : VACUUM, ANALYZE, REINDEX et leur automatisation ;
  • la sauvegarde, logique comme physique ;
  • la supervision, avec les journaux applicatifs et les statistiques d'activités, et un bref rappel des outils utilisables.

Je pense que cela a donné un aperçu complet sur PostgreSQL. Forcément, en une heure, on survole beaucoup de concepts, mais on ne peut guère attendre mieux d'un aperçu. Pour les curieux, les slides sont sur dalibo.org.

Dimitri a pris la suite, avec une autre conférence d'une heure elle-aussi. Sa conférence portait sur un exemple de développement. Il y avait beaucoup d'informations sur l'écriture de requêtes (CTE, requête de fenêtrage, etc.). Les requêtes finales étaient vraiment impressionnantes.

Il y avait une centaine de personnes dans l'amphithéâtre. Je m'attendais plutôt à une vingtaine de personnes, la surprise a été très agréable.

La soirée s'est terminée au restaurant, dans un bouchon lyonnais. Bonne bouffe, excellent vin, et très bonne compagnie. Une bonne conclusion à ce voyage éclair à Lyon.

Merci aux organisateurs, notamment Gautier et Michael.

par Guillaume Lelarge le jeudi 1 novembre 2012 à 17h37

mercredi 10 octobre 2012

Damien Clochard

Session PostgreSQL #4 : Migrer d'Oracle à PostgreSQL

Hasard du calendrier la 4eme Session PostgreSQL se tenait jeudi 4 octobre, dernier jour de la conférence Oracle Open World. Autant dire tout de suite que les deux événements n'avaient pas la même définition du mot "Open" !

Comme à chaque session, la salle était pleine pour écouter les interventions. La matinée fut consacrée en particulier aux outils de migrations eux-mêmes avec les 3 grandes méthodes : ora2pg, ETL ou Foreign Data Wrapper :

  • Jean-Paul Argudo a ouvert la conférence avec une keynote pour rappeler les enjeux et les problématiques des migrations de SGBD
  • Guillaume Lelarge a débuté avec une présentation rapide des nouveautés de PostgreSQL 9.2
  • Gilles Darold a poursuivi avec un zoom d' ora2pg l'outil de migration Oracle vers PostgreSQL dont il est l'auteur
  • Marc Cousin a décrit la mise en oeuvre de Kettle (un ETL open source)
  • Laurenz Albe, DBA à la mairie de Vienne en Autriche, a présenté le connecteur oracle_fdw qui permet de lire des tables Oracle à partir de PostgreSQL

L'après-midi fut l'occasion de faire un tour d'horizon des alternatives aux outils traditionnels d'Oracle, notamment

  • Gabriele Bartolini, fondateur de 2ndQuadrant Italie, a présenté Barman, un outil de backup qui marche sur les pas de RMAN
  • Jehan-Guillaume De Rorthais a décrit les nouveautés de pgBadger, un outil d'analyses de traffic SQL
  • Enfin Julien Rouhaud a conclu avec une présentation de PGXC, une solution de réplication symétrique ("Master-Master") qui vient chasser les terres d'Oracle RAC.

Toutes les présentations sont disponibles au format PDF ici : http://www.postgresql-sessions.org/4/start

Pour ma part, j'ai cloturé cette journée avec les conclusions suivantes :

1- Pour migrer d'Oracle vers PostgreSQL, vous avez le choix des armes : selon vos besoins et la complexité de votre schéma de données, vous pouvez utiliser différents outils : ora2pg est spécialisé et très simple à mettre en oeuvre. Kettle (et les autres ETL) sont très puissants et utiles si vous devez transformer les données. Enfin le connecteur oracle_fdw propose une solution originale pour migrer en douceur.

2- PostgreSQL a encore un peu de chemin à parcourir dans certains domaines: notamment sur la partitionnement ou sur les alternatives à OEM. Cela conduit beaucoup d'observateurs a juger qu' "Oracle est en avance sur PostgreSQL". Pour ma part, je ne m'attache pas à regarder la position de chaque SGBD à un instant T. Je préfère m'intéresser à la dynamique de chaque projet... Et cette journée de conférence a bien montré que la communauté PostgreSQL est actuellement dans une phase de développement extra-ordinaire et l'essor actuel est l'assurance que PostgreSQL sera un SGBD dominant dans les années à venir. Pour le dire autrement, en prenant la métaphore de la course à pied : le projet PostgreSQL est peut-être en seconde position derrière Oracle, mais vu sa vitesse actuelle il va rapidement rejoindre et dépasser la concurrence.

3- Comme l'a rappelé Jean-Paul en ouverture, une migration de SGBD c'est 10% de technique et 90% d'humain. La bonne nouvelle, c'est justement que l'open source remet l'humain au centre de la technologie. En effet, en passant d'un SGBD propriétaire à PostgreSQL, le cout de possession (TCO) change de nature: on ne paie plus de licences hors de prix à une multi-nationale ! Le budget est réorienté vers du service (Support, Formation, Conseil) via des opérateurs locaux et multiples. Passer au logiciel libre ce n'est pas uniquement un changement technique, c'est aussi (et surtout) une révolution au niveau de la relation commerciale.

Pour terminer, je remercie chaleuresement toute les personnes qui ont rendu cette journée possible notamment Laurentz Albe et Gabriele Bartolini.

La prochaine session se tiendra début 2013. Nous réfléchissons actuellement au thème de cette journée. N'hésitez pas à nous soumettre vos idées et vos propositions à l'adresse contact@postgresql-sessions.org. Et pour rester informé, suivez-nous sur twitter !

par damien le mercredi 10 octobre 2012 à 08h17

mardi 9 octobre 2012

Damien Clochard

PostgreSQL Conference Europe 2012 : Dernières chances pour vous inscrire

Il ne reste plus que deux semaines avant PostgreSQL Conference Europe 2012, qui se tiendra à l'hotel Corinthia Hotel de Prague en République Tchèque du 23 au 26 octobre. Plus de détails sur http://2012.pgconf.eu/

Avec 40 sessions destinées aux développeurs, DBA et décideurs, la conférence s'adressent à toutes les personnes intéressées par PostgreSQL et ses logiciels satellites. La session d'ouverture sera assurée par Joe Celko, vétéran de l'industrie, auteur renommée et co-rédacteur du standard SQL.

En complément, le programme contient des sessions de formations animées par des membres reconnus de la communauté tels que Bruce Momjian (co-fondateur du projet), Greg Smith (expert en performance) ou encore Joe Celko lui-même.

La conférence affiche complet mais quelques places supplémentaires de dernières minutes ont pu être ajoutées. Inscrivez-vous dès maintenant si ce n'est pas encore fait !

http://2012.pgconf.eu/registration/

par damien le mardi 9 octobre 2012 à 19h15

lundi 1 octobre 2012

Dimitri Fontaine (2nd Quadrant)

PostgreSQL fait sa rentrée

La bousculade de la rentrée retombe comme un bon soufflet, il est temps de prendre un peu de recul sur cette période mouvementée.

Une nouvelle version de PostgreSQL est maintenant disponible, il s’agit de la 9.2. C’est une version qui apporte de nouvelles fonctionnalités dans les domaines de la modélisation de données, de l’efficacité des requêtes, de la réplication de données et des performances en lecture et en écriture avec un grand nombre de clients connectés. Autant dire qu’il s’agit d’une nouvelle version majeure à ne manquer sous aucun prétexte!

Postgres Open

Nous avons eu l’occasion de revenir en détails sur plusieurs de ces fonctionnalités lors de la conférence américaine Postgres Open à Chicago. Dimitri a eu le plaisir d’y présenter une migration de grande échelle depuis MySQL vers PostgreSQL. Nous aurons une prochaine conférence au contenu comparable en Europe à Prague très bientôt, avec PostgreSQL Conference Europe 2012. Si vous n’êtes pas encore inscrits, pensez à le faire rapidement, les places partent vraiment très vite cette année! Nous espérons avoir le plaisir de vous y croiser, en particulier lors de l’une de nos présentations.

Cédric Villemain expliquera comment obtenir et valider les métriques de performances de vos installation PostgreSQL et Dimitri Fontaine présentera comment exploiter les techniques de réplication et de durabilité des données proposées par PostgreSQL afin d’atteindre les objectifs de fiabilité requis par votre projet.

Enfin, un grand merci au gouvernement français, qui vient par cette circulaire intitulée Orientation Pour l’Usage des Logiciels Libres dans l’Administration de reconnaître la place toute particulière de PostgreSQL au sein des institutions françaises. Nous sommes fiers de participer à la mise au point de ce logiciel, ainsi qu’à ses déploiements en production, et sommes heureux de pouvoir renouveler notre engagement dans une solution plébicitée par Monsieur le Premier Ministre, en tant que contributeurs et en tant qu’experts.

Conserver un tel rythme après la rentrée ne sera pas une mince affaire !

par Dimitri Fontaine le lundi 1 octobre 2012 à 09h53

dimanche 30 septembre 2012

Guillaume Lelarge

Nouvelle version de pgSnap

Ça fait facilement 10 mois que je n'avais pas travaillé sur pgSnap. Là, c'était vraiment nécessaire, notamment suite à la sortie de la version 9.2 de PostgreSQL et de toutes les petites modifications du schéma système que cela implique. Donc pas de grosses nouveautés sur cette version : quelques corrections de bugs et surtout le support complet de la 9.2.

Pour le télécharger, c'est sur github maintenant.

par Guillaume Lelarge le dimanche 30 septembre 2012 à 13h09

Nouvelles versions mineures du manuel

De nouveau, la mise à jour de la documentation s'est fait un peu attendre. La faute à un week-end bien rempli et à une semaine en déplacement. Néanmoins, les mises à jour sont disponibles sur le site de la documentation française.

par Guillaume Lelarge le dimanche 30 septembre 2012 à 08h31

Membres de la planète PGFR

S'abonner

PostgreSQL en Français:

Dernière mise à jour:
jeudi 23 mai 2013 à 01h41


Propulsé par: Planet