PostgreSQL La base de donnees la plus sophistiquee au monde.

La planète francophone de PostgreSQL

vendredi 27 janvier 2012

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 22 janvier 2012

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en janvier

PostgreSQL Local

  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague.
  • La PGCon 2012 sera tenue à l'Université d'Ottawa, les 17 et 18 mai 2012. Elle sera précédée par deux jours de tutoriels les 15 & 16 mai 2012 : http://www.pgcon.org/2012/

PostgreSQL dans les média

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

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

(lien vers l'article original)

Correctifs appliqués

Robert Haas a poussé :

Peter Eisentraut a poussé :

Alvaro Herrera a poussé :

  • Disallow merging ONLY constraints in children tables. When creating a child table, or when attaching an existing table as child of another, we must not allow inheritable constraints to be merged with non-inheritable ones, because then grandchildren would not properly get the constraint. This would violate the grandparent's expectations. Bugs noted by Robert Haas. Author: Nikhil Sontakke http://git.postgresql.org/pg/commitdiff/3b11247aadf857bbcbfc765191273973d9ca9dd7

Magnus Hagander a poussé :

Heikki Linnakangas a poussé :

  • Fix corner case in cleanup of transactions using SSI. When the only remaining active transactions are READ ONLY, we do a "partial cleanup" of committed transactions because certain types of conflicts aren't possible anymore. For committed r/w transactions, we release the SIREAD locks but keep the SERIALIZABLEXACT. However, for committed r/o transactions, we can go further and release the SERIALIZABLEXACT too. The problem was with the latter case: we were returning the SERIALIZABLEXACT to the free list without removing it from the finished list. The only real change in the patch is the SHMQueueDelete line, but I also reworked some of the surrounding code to make it obvious that r/o and r/w transactions are handled differently -- the existing code felt a bit too clever. Dan Ports http://git.postgresql.org/pg/commitdiff/326b922e8b2d65257a635b5f80e5de0f15dffd3a
  • Make pg_relation_size() and friends return NULL if the object doesn't exist. That avoids errors when the functions are used in queries like "SELECT pg_relation_size(oid) FROM pg_class", and a table is dropped concurrently. Phil Sorber http://git.postgresql.org/pg/commitdiff/fa352d662e57fa150158b9cb0a8f127250f8c97f

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Peter Geoghegan and Heikki Linnakangas traded new revisions of the GROUP COMMIT patch.
  • Greg Smith sent in a patch to publish checkpoint timing and sync files summary data to pg_stat_bgwriter.
  • Greg Smith sent in a patch to implement an unconditional checkpoint sync pause.
  • Andrew Dunstan sent in another revision of the patch to make pretty-printing view definitions actually print them prettily.
  • Fujii Masao sent in another revision of the patch to add a "write" replication mode.
  • Magnus Hagander sent in a patch to patch add a counter for the number of deadlocks in a database to pg_stat_database.
  • Tom Lane sent in a WIP patch for parameterized inner paths.
  • Fujii Masao sent in another revision of the patch to allow taking a base backup from a hot standby. Steve Singer reviewed same.
  • Alexander Korotkov sent in two more revisions of the patch to collect frequency statistics for arrays, the second per review by Noah Misch.
  • Kyotaro HORIGUCHI sent in another revision of the patch to speed dblink using a new libpq tuple storage system. Marko Kreen and Marc Mamin reviewed.
  • Greg Smith sent in a patch to add a pg_test_timing.
  • Tomas Vondra sent in another revision of the patch to track temp files in pg_stat_database. Magnus Hagander reviewed same.
  • Heikki Linnakangas sent in another revision of the bgwriter latch patch intended to save energy.
  • Daniel Farina sent in two revisions of a patch to factor out the various CRC32 implementations in the PostgreSQL source code, per reviews by Tom Lane and Robert Haas.
  • Martin Pihlak sent in two more revisions of the patch to add logging hooks.
  • Martin Pihlak sent in another revision of the patch to generate call graphs in real time, per review by Joel Jacobson.
  • KaiGai Kohei sent in two more revisions of the patch to implement sepgsql's DROP permissions.
  • Peter Geoghegan sent in another revision of the fast path sorting patch.
  • Simon Riggs sent in another revision of the patch to implement DROP INDEX CONCURRENTLY, reviewed by Robert Haas.
  • Peter Eisentraut sent in another revision of the collation for expression patch.
  • Simon Riggs sent in two more revisions of the walrestore patch, per reviews by Fujii Masao.
  • Heikki Linnakangas sent in another revision of the patch to move work out of WALInsertLock(), per review by Robert Haas.
  • Dimitri Fontaine sent in another revision of the inline EXTENSION patch per review by Robert Haas.
  • Euler Taveira de Oliveira sent in two more patches to implement xlog arithmetic.
  • Noah Misch sent in another revision of the patch to avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE.
  • Noah Misch sent in a patch to fix a defective test case.
  • Simon Riggs sent in another revision of a patch to fix certain kinds of CLOG contention.
  • KaiGai Kohei sent in two more revisions of the patch to add a LEAKPROOOF attribute to functions per review by Robert Haas.
  • Peter Eisentraut sent in another revision of the patch to remove unused-variable warnings in assert-free builds.
  • KaiGai Kohei sent in a patch to fix some infelicities in the changes that plug certain kinds of information leakage in views.
  • Julien Tachoires sent in another revision of the patch to allow toast tables to be moved to a different tablespace.
  • Mikko Tiihonen sent in another revision of the patch to create a new, more space-efficient serialization for arrays with fix-length elements.
  • Tom Lane sent in a patch to fix bug 6123.

par N Bougain le vendredi 27 janvier 2012 à 12h16

mercredi 25 janvier 2012

Damien Clochard

Session PostgreSQL #3 : il ne reste plus qu'une poignée de places !

Visiblement nous avons visé juste ! En choisissant la Réplication comme thème de la prochaine Session PostgreSQL nous savions que le public répondrait nombreux mais nous n'avions pas prévu un tel engouement... Le conférence qui se tiendra le 2 février à Paris affiche quasiment complet ! Au moment ou j'écris ces lignes , il ne reste plus qu'une poignée de places disponibles. Si vous êtes intéressé par les problématiques de Haute-Disponibité sous PostgreSQL, je vous encourage à vous inscrire le plus rapidement possible à cette adresse :

http://www.postgresql-sessions.org/3/registration_form

Pour rappel, la session se tiendra de 9h30 à 17h30 au Comptoir Général situé 80 quai de Jemmapes à Paris ( http://osm.org/go/0BPIqc7Q )

Parmi les orateurs, nous aurons la chance de compter :

  • Mickaël Paquier (Japon), Développeur de Postgres-XC
  • Simon Riggs (Angleterre), Contibuteur majeur de PostgreSQL
  • Ludovic Levesque (France), Directeur Technique de Fotolia

Le programme complet est disponible ici : http://www.postgresql-sessions.org/3/

Rendez-vous le 2 février à Paris !

par damien le mercredi 25 janvier 2012 à 19h26

lundi 23 janvier 2012

Damien Clochard

FOSDEM 2012 : Demandez le programme !

Le FOSDEM 2012 se tiendra du 4 au 5 février à Bruxelles. C'est un rendez-vous important de la communauté européenne de PostgreSQL et comme d'habitude vous retrouverez pas mal de francophones derrière le stand de l'association PostgreSQL Europe !

Rappelons que le FOSDEM est un événement gratuit et sans inscriptions. Plus d'informations par ici : http://fosdem.org/2012/

Cette année encore, il y a une journée entière de conférences (en anglais) dédiée à PostgreSQL :

http://fosdem.org/2012/schedule/track/postgresql_devroom

Rendez-vous à Bruxelles le 4-5 février !

par damien le lundi 23 janvier 2012 à 20h16

dimanche 22 janvier 2012

Stephane Bortzmeyer

Changer une base PostgreSQL de « tablespace »

Un des principaux mécanismes de gestion de l'espace disque dans PostgreSQL est le tablespace (http://www.postgresql.org/docs/8.4/interactive/manage-ag-tablespaces.html). Un tablespace est un répertoire où on place des données du SGBD. Mais, si on change d'avis, comment changer une base de tablespace ?

dimanche 22 janvier 2012 à 00h00

lundi 16 janvier 2012

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 15 janvier 2012

La Commitfest n°4 est lancée. Commencez à relire ces patchs ! https://commitfest.postgresql.org/action/commitfest_view?id=13

La PGCon 2012 sera tenue à l'Université d'Ottawa, les 17 et 18 mai 2012. Elle sera précédée par deux jours de tutoriels les 15 & 16 mai 2012 : http://www.pgcon.org/2012/

Offres d'emplois autour de PostgreSQL en janvier

PostgreSQL Local

  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT 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

Magnus Hagander a poussé :

Robert Haas a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Fix one-byte buffer overrun in contrib/test_parser. The original coding examined the next character before verifying that there *is* a next character. In the worst case with the input buffer right up against the end of memory, this would result in a segfault. Problem spotted by Paul Guyot; this commit extends his patch to fix an additional case. In addition, make the code a tad more readable by not overloading the usage of *tlen. http://git.postgresql.org/pg/commitdiff/89b3c6cc8b560f7f46a6a25b270aed5330c09a0e
  • Tweak duplicate-index-column regression test to avoid locale sensitivity. The originally-chosen test case gives different results in es_EC locale because of unusual rule for sorting strings beginning with "LL". Adjust the comparison value to avoid that, while hopefully not introducing new locale dependencies elsewhere. Per report from Jaime Casanova. http://git.postgresql.org/pg/commitdiff/de5a08c59de39df07599723cb212ae8297903f48
  • Fix CLUSTER/VACUUM FULL for toast values owned by recently-updated rows. In commit 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05, I made CLUSTER and VACUUM FULL try to preserve toast value OIDs from the original toast table to the new one. However, if we have to copy both live and recently-dead versions of a row that has a toasted column, those versions may well reference the same toast value with the same OID. The patch then led to duplicate-key failures as we tried to insert the toast value twice with the same OID. (The previous behavior was not very desirable either, since it would have silently inserted the same value twice with different OIDs. That wastes space, but what's worse is that the toast values inserted for already-dead heap rows would not be reclaimed by subsequent ordinary VACUUMs, since they go into the new toast table marked live not deleted.) To fix, check if the copied OID already exists in the new toast table, and if so, assume that it stores the desired value. This is reasonably safe since the only case where we will copy an OID from a previous toast pointer is when toast_insert_or_update was given that toast pointer and so we just pulled the data from the old table; if we got two different values that way then we have big problems anyway. We do have to assume that no other backend is inserting items into the new toast table concurrently, but that's surely safe for CLUSTER and VACUUM FULL. Per bug #6393 from Maxim Boguk. Back-patch to 9.0, same as the previous patch. http://git.postgresql.org/pg/commitdiff/21b446dd0927f8f2a187d9461a0d3f11db836f77

Heikki Linnakangas a poussé :

Alvaro Herrera a poussé :

Simon Riggs a poussé :

Andrew Dunstan a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Peter Eisentraut sent in a patch to make variable-length pg_catalog fields invisible in pg_* C structs.
  • Joel Jacobson sent in two revisions of a patch to create call graphs for UDF function calls inside PostgreSQL.
  • Joachim Wieland sent in a patch to allow master databases to send NOTIFYs to replicas.
  • Robert Haas and Andrew Dunstan traded patches to add JSON types and associated infrastructure.
  • Ryan Kelly and Heikki Linnakangas traded patches to allow breaking out of hung connection attempts in libpq.
  • KaiGai Kohei sent in a patch to add a new GUC: sepgsql.client_label, which allows a client process to switch its privileges into another one, as long as the system security policy allows this transition.
  • KaiGai Kohei sent a patch to add OAT_DROP object access hook around the permission checks of object deletion.
  • David Fetter sent in a patch by Dan Scales to add double-write, which among other things gets durability guarantees without the same overhead as full_page_writes.
  • Robert Haas sent in a patch intended to ensure checkpoint writeback via sync_file_range where this call is available.
  • Simon Riggs sent in another revision of the patch to allow logging messages for archive recovery progress.
  • Peter Eisentraut sent in a patch to add .colnames() and .coltypes() methods to PL/PythonU.
  • Peter Eisentraut sent in a patch to make psql's tab completion preserve the case the completion was started in rather than unconditionally upper-casing keywords.
  • Peter Eisentraut sent in a patch to add a command ALTER TABLE ... RENAME CONSTRAINT.
  • Thomas Munro sent in a patch to rename sequences automatically in cases where this makes sense.
  • Scott Mead sent in another revision of the patch to allow introspecting "IDLE IN TRANSACTION" situations.
  • Noah Misch sent in another revision of the patch to collect frequency statistics for arrays.
  • Simon Riggs sent in another revision of the patch to remove CLOG contention caused by dirty CLOG LRU.
  • Kevin Grittner and Tom Lane traded patches to fix bug #6123 http://archives.postgresql.org/pgsql-bugs/2011-07/msg00138.php
  • Robert Haas sent in a patch to measure spinning.
  • Simon Riggs sent in a patch to simulate CLOG contention.
  • Simon Riggs sent in a patch to add a new -x option for pgbench which executes the given command once after connection of each session.
  • Simon Riggs sent in a patch to ensure that the correct code, ERRCODE_READ_ONLY_SQL_TRANSACTION, be sent in all remaining cases for illegal actions on a standby.
  • Fujii Masao sent in a patch to add a "write" replication mode for synchronous replication.
  • Fujii Masao sent in another revision of the patch to allow taking an online base backup from a standby.
  • Dimitri Fontaine sent in another revision of the patch to add triggers on commands.
  • Robert Haas sent in a patch to fix an issue where concurrent CREATE TABLE/DROP SCHEMA can leave inconsistent leftovers.
  • Greg Smith sent in a patch to speed up dblink by creating and using a new libpq tuple storage system.
  • Fujii Masao sent in a patch intended to correct an issue where replay_location indicates an incorrect location.
  • Robert Haas sent in a patch which shows Heap Fetches in EXPLAIN for index-only scans.
  • Tomas Vondra sent in another revision of the patch to allow EXPLAIN ANALYZE with rows but not timing information.
  • Alvaro Herrera sent in another revision of the patch to add foreign key locks.
  • Marco Nenciarini sent in another revision of the patch to make it possible to enforce arrays of foreign keys.
  • Peter Eisentraut sent in a patch to implement specific -A (auth) options for initdb, namely --auth-local and --auth-host.
  • Heikki Linnakangas sent in another revision of the patch to move work outside WALInsertLock.
  • Peter Eisentraut sent in a patch to allow GUC control of the location of server-side SSL files.
  • Peter Eisentraut sent in a patch to allow using the NUL byte as a field or record separator in psql output.
  • Noah Misch sent in a patch to make psql's filename completion work with filenames that contain one or more spaces.
  • Noah Misch sent in a patch to fix several infelicities in psql's handling of COPY.
  • Matthew Draper sent in a patch to allow SQL language functions to reference parameters by name. And there was much rejoicing!
  • Peter Eisentraut sent in a patch to clean up a lot of warnings in assert-free builds.
  • Jaime Casanova sent in a patch to add a pg_stats_recovery view.
  • Ants Aasma sent in another revision of the patch to add timing of buffer I/O requests.
  • Peter Eisentraut sent in a patch to change the exit() calls in libraries to abort()s.
  • Simon Riggs sent in a patch to enable keepalive on quiet systems that are replicating.
  • Jaime Casanova sent in a patch which adds checks to pg_basebackup to ensure that the system-set number of fields is actually there.
  • Greg Smith sent in a patch to add a GUC which rate-limits VACUUMs in kB/sec.
  • Simon Riggs sent in a patch to change the walrestore process so it asynchronously executes restore_command while recovery continues working.
  • Joachim Wieland sent in another revision of the patch to parallelize pg_dump.
  • Kevin Grittner sent in another revision of the patch to add a function which shows trigger depth.
  • Peter Geoghegan sent in another revision of the patch to allow group commit.
  • Jeff Janes sent in a patch to calculate memory for sorts more precisely and use it more efficiently.
  • Kevin Grittner sent in another revision of the patch to generalize trigger functionality for any operation after each row of any table with a primary key. This is called trigger_change_notification.

par N Bougain le lundi 16 janvier 2012 à 23h18

Nouvelles hebdomadaires de PostgreSQL - 8 janvier 2012

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en janvier

PostgreSQL Local

  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Bruce Momjian a poussé :

Tom Lane a poussé :

  • Fix coerce_to_target_type for coerce_type's klugy handling of COLLATE. Because coerce_type recurses into the argument of a CollateExpr, coerce_to_target_type's longstanding code for detecting whether coerce_type had actually done anything (to wit, returned a different node than it passed in) was broken in 9.1. This resulted in unexpected failures in hide_coercion_node; which was not the latter's fault, since it's critical that we never call it on anything that wasn't inserted by coerce_type. (Else we might decide to "hide" a user-written function call.) Fix by removing and replacing the CollateExpr in coerce_to_target_type itself. This is all pretty ugly but I don't immediately see a way to make it nicer. Per report from Jean-Yves F. Barbier. http://git.postgresql.org/pg/commitdiff/ac7a5a3f25708c03242edc301ad008236fc36c7e
  • Use a non-locking initial test in TAS_SPIN on PPC. Further testing convinces me that this is helpful at sufficiently high contention levels, though it's still worrisome that it loses slightly at lower contention levels. Per Manabu Ori. http://git.postgresql.org/pg/commitdiff/bc2a050d40976441cdb963ad829316c23e8df0aa
  • Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. http://git.postgresql.org/pg/commitdiff/dfd26f9c5f371437f243249025863ea9911aacaa
  • Fix pg_restore's direct-to-database mode for INSERT-style table data. In commit 6545a901aaf84cb05212bb6a7674059908f527c3, I removed the mini SQL lexer that was in pg_backup_db.c, thinking that it had no real purpose beyond separating COPY data from SQL commands, which purpose had been obsoleted by long-ago fixes in pg_dump's archive file format. Unfortunately this was in error: that code was also used to identify command boundaries in INSERT-style table data, which is run together as a single string in the archive file for better compressibility. As a result, direct-to-database restores from archive files made with --inserts or --column-inserts fail in our latest releases, as reported by Dick Visser. To fix, restore the mini SQL lexer, but simplify it by adjusting the calling logic so that it's only required to cope with INSERT-style table data, not arbitrary SQL commands. This allows us to not have to deal with SQL comments, E'' strings, or dollar-quoted strings, none of which have ever been emitted by dumpTableData_insert. Also, fix the lexer to cope with standard-conforming strings, which was the actual bug that the previous patch was meant to solve. Back-patch to all supported branches. The previous patch went back to 8.2, which unfortunately means that the EOL release of 8.2 contains this bug, but I don't think we're doing another 8.2 release just because of that. http://git.postgresql.org/pg/commitdiff/f3316a05b5ddee619ba0617716a4fef3ceb29ded
  • Fix typo, pg_types_date.h => pgtypes_date.h. Spotted by Koizumi Satoru. http://git.postgresql.org/pg/commitdiff/7a72efda72a85eef1513f2a02449e24dc4bdfc74
  • Use __sync_lock_test_and_set() for spinlocks on ARM, if available. Historically we've used the SWPB instruction for TAS() on ARM, but this is deprecated and not available on ARMv6 and later. Instead, make use of a GCC builtin if available. We'll still fall back to SWPB if not, so as not to break existing ports using older GCC versions. Eventually we might want to try using __sync_lock_test_and_set() on some other architectures too, but for now that seems to present only risk and not reward. Back-patch to all supported versions, since people might want to use any of them on more recent ARM chips. Martin Pitt http://git.postgresql.org/pg/commitdiff/0a41e865845bfa5d7aafcc5fe000dafa26573fef

Peter Eisentraut a poussé :

Andrew Dunstan a poussé :

Michael Meskes a poussé :

Robert Haas a poussé :

  • Fix variable confusion in BufferSync(). As noted by Heikki Linnakangas, the previous coding confused the "flags" variable with the "mask" variable. The affect of this appears to be that unlogged buffers would get written out at every checkpoint rather than only at shutdown time. Although that's arguably an acceptable failure mode, I'm back-patching this change, since it seems like a poor idea to rely on this happening to work. http://git.postgresql.org/pg/commitdiff/7e4911b2ae33acff7b85234b91372133ec6df9d4
  • Make the number of CLOG buffers adaptive, based on shared_buffers. Previously, this was hardcoded: we always had 8. Performance testing shows that isn't enough, especially on big SMP systems, so we allow it to scale up as high as 32 when there's adequate memory. On the flip side, when shared_buffers is very small, drop the number of CLOG buffers down to as little as 4, so that we can start the postmaster even when very little shared memory is available. Per extensive discussion with Simon Riggs, Tom Lane, and others on pgsql-hackers. http://git.postgresql.org/pg/commitdiff/33aaa139e6302e81b4fbf2570be20188bb974c4f
  • Improve behavior of concurrent ALTER TABLE, and do some refactoring. ALTER TABLE (and ALTER VIEW, ALTER SEQUENCE, etc.) now use a RangeVarGetRelid callback to check permissions before acquiring a table lock. We also now use the same callback for all forms of ALTER TABLE, rather than having separate, almost-identical callbacks for ALTER TABLE .. SET SCHEMA and ALTER TABLE .. RENAME, and no callback at all for everything else. I went ahead and changed the code so that no form of ALTER TABLE works on foreign tables; you must use ALTER FOREIGN TABLE instead. In 9.1, it was possible to use ALTER TABLE .. SET SCHEMA or ALTER TABLE .. RENAME on a foreign table, but not any other form of ALTER TABLE, which did not seem terribly useful or consistent. Patch by me; review by Noah Misch. http://git.postgresql.org/pg/commitdiff/1489e2f26a4c0318938b3085f50976512f321d84
  • Fix backwards logic in previous commit. I wrote this code before committing it, but managed not to include it in the actual commit. http://git.postgresql.org/pg/commitdiff/df970a0ac8fb416b179825a135c18ad3293076af
  • Slightly reorganize struct SnapshotData. This squeezes out a bunch of alignment padding, reducing the size from 72 to 56 bytes on my machine. At least in my testing, this didn't produce any measurable performance improvement, but the space savings seem like enough justification. Andres Freund http://git.postgresql.org/pg/commitdiff/1fc3d18faa8f4476944bc6854be0f7f6adf4aec8

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Noah Misch and Simon Riggs traded patches to make SnapshotNow an MVCC snapshot.
  • Pavel Stehule sent in three revisions of a patch to add IF EXISTS to ALTER TABLE for tables which may or may not exist.
  • Simon Riggs sent in two patches offering differing mitigations to PostgreSQL's lame buffer replacement strategy.
  • KaiGai Kohei sent in two revisions of a new patch to control information leaks from certain kinds of views.
  • Alexander Korotkov sent in two more revisions of a patch to collect frequency statistics for arrays.
  • Simon Riggs sent in a patch to check for busy state before putting buffer on the freelist.
  • Simon Riggs sent in two revisions of a patch to avoid some lock contention.
  • Andrew Dunstan sent in a cleaned-up version of Brad Davis patch to bring the FreeBSD kernel tuning documentation up to date.
  • Peter Geoghegan sent in two revisions of a patch to save energy by having a bgwriter latch.
  • Noah Misch sent in two revisions of a patch to prevent foreign key validations for ALTER TABLE ... ALTER TYPE where table rewriting is not already happening.
  • Simon Riggs sent in a patch to remove clog contention caused by his dirty CLOG LRU.
  • Simon Riggs sent in six more revisions of a patch to add 16-bit page checksums without changing the page format.
  • Robert Haas sent in a WIP patch to optimize repeated MVCC snapshots by reusing same if no transactions have committed or aborted since it was taken.
  • Jim Mlodgenski sent in a patch intended to allow psql to display client messages.
  • Robert Haas sent in a patch to fix how a loop works in VACUUM.
  • Dan Ports sent in a patch to fix a corner case in the SSI cleanup code that isn't handled correctly.
  • Noah Misch sent in a patch to tighten up two issues introduced in his previous patch, which introduced a CheckIndexCompatible() that approves btree and hash indexes having changed to a different operator class within the same operator family.
  • Heikki Linnakangas sent in anoTher revision of his patch to move more work outside WALInsertLock.
  • Heikki Linnakangas sent in a patch to allow profiling LWLocks.
  • KaiGai Kohei sent in a patch which adds the option to assert that a function is leakproof in the sense that it can be pushed down into a view and not leak information. This goes to the effort to prevent certain kinds of information leaks in views.
  • Simon Riggs sent in a patch which adds a ClogHistory cache which allows access to the read-only tail of pages in the clog. This separates historical accesses by readers from current write access by committers.
  • Dimitri Fontaine sent in a patch to add in-line extensions, namely ones which do not require access to the filesystem or network in order to work.
  • Peter Eisentraut sent in a patch to add tab completion for GRANT role to psql.
  • Peter Eisentraut sent in a patch to add the SQL standard "collation for (expression)" feature.
  • Ryan Kelly sent in a patch to fix some misbehavior when psql connects to a non-existent host.

par N Bougain le lundi 16 janvier 2012 à 01h38

vendredi 6 janvier 2012

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 1er janvier 2012

Bonne Année de la part des Nouvelles Hebdomadaires de PostgreSQL !

Les nouveautés des produits dérivés

PostgreSQL Local

  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Alvaro Herrera a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Adjust SP-GiST regression tests to be less locale-sensitive. The original test cases gave varying results depending on whether the locale sorts digits before or after letters. Since that's not really what we wish to test here, adjust the test data to not contain any strings beginning with digits. Per report from Pavel Stehule. http://git.postgresql.org/pg/commitdiff/15ba590792045a6bbde538c407a34d83f46b496f
  • Revert "Remove troublesome Asserts in cost_mergejoin()." This reverts commit ff68b256a533b398e3420750f34d161aeee4e099. The recent change to use -fexcess-precision=standard should make those Asserts safe, and does fix a test case that formerly crashed for me, so I think there's no need to have a cross-version difference in the code here. http://git.postgresql.org/pg/commitdiff/2ae2e9c00798685cd75ea0cc5120466bf2027b90
  • Use mutex hint bit in PPC LWARX instructions, where possible. The hint bit makes for a small but measurable performance improvement in access to contended spinlocks. On the other hand, some PPC chips give an illegal-instruction failure. There doesn't seem to be a completely bulletproof way to tell whether the hint bit will cause an illegal-instruction failure other than by trying it; but most if not all 64-bit PPC machines should accept it, so follow the Linux kernel's lead and assume it's okay to use it in 64-bit builds. Of course we must also check whether the assembler accepts the command, since even with a recent CPU the toolchain could be old. Patch by Manabu Ori, significantly modified by me. http://git.postgresql.org/pg/commitdiff/5cfa8dd3007d7e953c6a03b0fa2215d97c581b0c
  • Use 4-byte slock_t on both PPC and PPC64. Previously we defined slock_t as 8 bytes on PPC64, but the TAS assembly code uses word-wide operations regardless, so that the second word was just wasted space. There doesn't appear to be any performance benefit in adding the second word, so get rid of it to simplify the code. http://git.postgresql.org/pg/commitdiff/8496c6cd77e2f5f105fc47315680174157d66647
  • Use LWSYNC in place of SYNC/ISYNC in PPC spinlocks, where possible. This is allegedly a win, at least on some PPC implementations, according to the PPC ISA documents. However, as with LWARX hints, some PPC platforms give an illegal-instruction failure. Use the same trick as before of assuming that PPC64 platforms will accept it; we might need to refine that based on experience, but there are other projects doing likewise according to google. I did not add an assembler compatibility test because LWSYNC has been around much longer than hint bits, and it seems unlikely that any toolchains currently in use don't recognize it. http://git.postgresql.org/pg/commitdiff/631beeac3598a73dee2c2afa38fa2e734148031b

Bruce Momjian a poussé :

Simon Riggs a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Simon Riggs sent in two more revisions of the patch to add page checksums.
  • Alexander Björnhagen sent in two more revisions of the patch to tune synchronous replication.
  • Brar Piening sent in two more revisions of the patches to support VS 2010.
  • Andrew Dunstan sent in another revision of the patch to make pretty-printing view definitions actually print them in a pretty way.
  • Peter Eisentraut sent in a patch to fix an infelicity in CREATE TABLE ... LIKE.
  • Peter Eisentraut sent in a patch to make the dumping of FOREIGN ... OPTIONS more legible.
  • Simon Riggs sent in another revision of the patch to pause at the end of recovery.
  • Peter Geoghegan sent in another revision of the fast path sorting patch, along with some benchmarks demonstrating its usefulness.
  • Simon Riggs sent in a patch to implement DROP INDEX CONCURRENTLY.
  • Noah Misch sent in a patch to add protransform functions to the length coercions for numeric, varbit, timestamp, timestamptz, time, timetz and interval. This prevents whole-table rewrites in some ALTER TABLE ... ALTER COLUMN ... TYPE ... statements involving the aforementioned types.
  • Noah Misch sent in another revision of the patch to collect frequency statistics for arrays.
  • Zoltan Boszormenyi sent in another revision of the patch to fix ECPG cursor readahead.
  • Pavel Stehule sent in another revision of the CHECK FUNCTION patch.
  • Peter Eisentraut sent in a WIP patch intended to inform the information schema about default privileges.
  • Peter Eisentraut sent in a WIP patch to relax the requirement that PL/pgsql trigger functions return a value when called in AFTER triggers.
  • Peter Eisentraut sent in a patch to fix the sorting of operators in pg_dump.

par N Bougain le vendredi 6 janvier 2012 à 23h21

mercredi 4 janvier 2012

Damien Clochard

Session PostgreSQL #3 le 2 février: Réplication PostgreSQL

Dalibo organise le jeudi 2 février 2012 à Paris une rencontre internationale consacrée au Système de Gestion de Bases de Données PostgreSQL.

Le thème de cette journée sera la réplication, avec des invités de marques notamment :

 * Mickaël Paquier (Japon), Développeur de Postgres-XC
 * Simon Riggs (Angleterre), Contibuteur majeur de PostgreSQL
 * Ludovic Levesque (France), Directeur Technique de Fotolia

L'objectif de cette conférence est de faire un tour d'horizon des solutions de Haute-disponibilités : PGXC, Slony, Londiste et avec bien sûr un accent particulier la réplication interne avec le Hot Standby / Streaming Replication !

Retrouvez le programme complet sur le site de l'évènement : http://www.postgresql-sessions.org/...

La session se tiendra de 9h30 à 17h30 au Comptoir Général situé 80 quai de Jemmapes à Paris ( http://osm.org/go/0BPIqc7Q )

Cet événement est gratuit et ouvert à tous, dans la limite des places disponibles.

Les inscriptions se font via la page ci-dessous : http://www.postgresql-sessions.org/...

Pour toute précision, n'hésitez pas à envoyer un message à contact@postgresql-sessions.org

Bonne journée et Rendez-vous le 2 février juin à Paris !


À propos des Sessions PostgreSQL : Les sessions PostgreSQL sont avant tout des moments pour découvrir et rencontrer la communauté PostgreSQL. Chaque session est une journée composée de conférences et d'ateliers, organisée autour d'un thème précis et d'un invité de marque.

» site web : http://www.postgresql-sessions.org/


À propos de Dalibo : Spécialiste français de PostgreSQL, Dalibo met à la disposition de ses clients son savoir-faire dans le domaine des bases de données et propose des services de conseil, de formation et de support aux entreprises et aux institutionnels.

» site web : http://www.dalibo.com/

par damien le mercredi 4 janvier 2012 à 14h18

jeudi 29 décembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 25 décembre 2011

HTSQL 2.2, un langage de haut-niveau pour les bases de données relationnelles : http://htsql.org

psycopg2 2.4.3, un connecteur Python pour PostgreSQL : http://initd.org/psycopg/articles/2011/12/12/psycopg-243-released/

Offres d'emplois autour de PostgreSQL en décembre

PostgreSQL Local

  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • Teach SP-GiST to do index-only scans. Operator classes can specify whether or not they support this; this preserves the flexibility to use lossy representations within an index. In passing, move constant data about a given index into the rd_amcache cache area, instead of doing fresh lookups each time we start an index operation. This is mainly to try to make sure that spgcanreturn() has insignificant cost; I still don't have any proof that it matters for actual index accesses. Also, get rid of useless copying of FmgrInfo pointers; we can perfectly well use the relcache's versions in-place. http://git.postgresql.org/pg/commitdiff/92203624934095163f8b57b5b3d7bbd2645da2c8
  • Rename updateNodeLink to spgUpdateNodeLink. On reflection, the original name seems way too generic for a global symbol. A quick check shows this is the only exported function name in SP-GiST that doesn't begin with "spg" or contain "SpGist", so the rest of them seem all right. http://git.postgresql.org/pg/commitdiff/8f57b064fdaa682ddea60f5dc27c0a5d5fcbffab
  • Avoid crashing when we have problems unlinking files post-commit. smgrdounlink takes care to not throw an ERROR if it fails to unlink something, but that caution was rendered useless by commit 3396000684b41e7e9467d1abc67152b39e697035, which put an smgrexists call in front of it; smgrexists *does* throw error if anything looks funny, such as getting a permissions error from trying to open the file. If that happens post-commit, you get a PANIC, and what's worse the same logic appears in the WAL replay code, so the database even fails to restart. Restore the intended behavior by removing the smgrexists call --- it isn't accomplishing anything that we can't do better by adjusting mdunlink's ideas of whether it ought to warn about ENOENT or not. Per report from Joseph Shraibman of unrecoverable crash after trying to drop a table whose FSM fork had somehow gotten chmod'd to 000 permissions. Backpatch to 8.4, where the bogus coding was introduced. http://git.postgresql.org/pg/commitdiff/d0024cd1881447fa7aed58db94df379e593c6630
  • Fix gincostestimate to handle ScalarArrayOpExpr reasonably. The original coding of this function overlooked the possibility that it could be passed anything except simple OpExpr indexquals. But ScalarArrayOpExpr is possible too, and the code would probably crash (and surely give ridiculous answers) in such a case. Add logic to try to estimate sanely for such cases. In passing, fix the treatment of inner-indexscan cost estimation: it was failing to scale up properly for multiple iterations of a nestloop. (I think somebody might've thought that index_pages_fetched() is linear, but of course it's not.) Report, diagnosis, and preliminary patch by Marti Raudsepp; I refactored it a bit and fixed the cost estimation. Back-patch into 9.1 where the bogus code was introduced. http://git.postgresql.org/pg/commitdiff/1db5af279441b9ee215b54de424c2af92eeb1ef8
  • Update per-column ACLs, not only per-table ACL, when changing table owner. We forgot to modify column ACLs, so privileges were still shown as having been granted by the old owner. This meant that neither the new owner nor a superuser could revoke the now-untraceable-to-table-owner permissions. Per bug #6350 from Marc Balmer. This has been wrong since column ACLs were added, so back-patch to 8.4. http://git.postgresql.org/pg/commitdiff/c31224e257a57fc9ad1c602414d9f6f5f4ce4ae3
  • Improve planner's handling of duplicated index column expressions. It's potentially useful for an index to repeat the same indexable column or expression in multiple index columns, if the columns have different opclasses. (If they share opclasses too, the duplicate column is pretty useless, but nonetheless we've allowed such cases since 9.0.) However, the planner failed to cope with this, because createplan.c was relying on simple equal() matching to figure out which index column each index qual is intended for. We do have that information available upstream in indxpath.c, though, so the fix is to not flatten the multi-level indexquals list when putting it into an IndexPath. Then we can rely on the sublist structure to identify target index columns in createplan.c. There's a similar issue for index ORDER BYs (the KNNGIST feature), so introduce a multi-level-list representation for that too. This adds a bit more representational overhead, but we might more or less buy that back by not having to search for matching index columns anymore in createplan.c; likewise btcostestimate saves some cycles. Per bug #6351 from Christian Rudolph. Likely symptoms include the "btree index keys must be ordered by attribute" failure shown there, as well as "operator MMMM is not a member of opfamily NNNN". Although this is a pre-existing problem that can be demonstrated in 9.0 and 9.1, I'm not going to back-patch it, because the API changes in the planner seem likely to break things such as index plugins. The corner cases where this matters seem too narrow to justify possibly breaking things in a minor release. http://git.postgresql.org/pg/commitdiff/e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195
  • Rethink representation of index clauses' mapping to index columns. In commit e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 I made use of nested list structures to show which clauses went with which index columns, but on reflection that's a data structure that only an old-line Lisp hacker could love. Worse, it adds unnecessary complication to the many places that don't much care which clauses go with which index columns. Revert to the previous arrangement of flat lists of clauses, and instead add a parallel integer list of column numbers. The places that care about the pairing can chase both lists with forboth(), while the places that don't care just examine one list the same as before. The only real downside to this is that there are now two more lists that need to be passed to amcostestimate functions in case they care about column matching (which btcostestimate does, so not passing the info is not an option). Rather than deal with 11-argument amcostestimate functions, pass just the IndexPath and expect the functions to extract fields from it. That gets us down to 7 arguments which is better than 11, and it seems more future-proof against likely additions to the information we keep about an index path. http://git.postgresql.org/pg/commitdiff/472d3935a2793343e450ba7cda4adbc323a984c3

Alvaro Herrera a poussé :

Peter Eisentraut a poussé :

Robert Haas a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Jeff Davis sent in another revision of the patch to fix GiST indexing in range types.
  • Magnus Hagander sent in another revisions of the patch to allow users to kill their own queries.
  • Peter Eisentraut sent in a patch to disable prompting by default in the createuser utility.
  • Heikki Linnakangas sent in two revisions of a patch to move more work outside WALInsertLock.
  • Phil Sorber sent in three more revision of a patch to improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no-longer-visible relation.
  • Marti Raudsepp sent in a patch to enable min()/max() optimization for the bool_and and bool_or aggregates.
  • Tomas Vondra sent in two revisions of a patch to track temp files in pg_stat_database.
  • Alvaro Herrera sent in a WIP patch to separate the default search order of columns from the on-disk representation.
  • Simon Riggs sent in a WIP patch to fix some contention issues in CLOG.
  • Marti Raudsepp sent in a patch to fix handling of erroneous float values, at least on some platforms.
  • Andrew Dunstan sent in a patch to make pretty-printing of view definions do something that resembles actual pretty-printing. The previous way was quite ugly in common cases.
  • Tomas Vondra sent in two revisions of a patch to allow EXPLAIN ANALYZE to instrument rows, but not timing.
  • Simon Riggs sent in a patch to enable 16-bit page checksums.
  • Alexander Björnhagen sent in a patch to add a GUC to control whether a master configured with synchronous_commit = on is allowed to stop waiting for standby WAL sync when all synchronous standby WAL senders are disconnected.

par N Bougain le jeudi 29 décembre 2011 à 00h28

dimanche 25 décembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 18 décembre 2011

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en décembre

PostgreSQL Local

  • FOSDEM 2012 - Devroom PostgreSQL : l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/
  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Heikki Linnakangas a poussé :

Tom Lane a poussé :

  • Move BKP_REMOVABLE bit from individual WAL records to WAL page headers. Removing this bit from xl_info allows us to restore the old limit of four (not three) separate pages touched by a WAL record, which is needed for the upcoming SP-GiST feature, and will likely be useful elsewhere in future. When we implemented XLR_BKP_REMOVABLE in 2007, we had to do it like that because no special WAL-visible action was taken when starting a backup. However, now we force a segment switch when starting a backup, so a compressing WAL archiver (such as pglesslog) that uses the state shown in the current page header will not be fooled as to removability of backup blocks. The only downside is that the archiver will not return to compressing mode for up to one WAL page after the backup is over, which is a small price to pay for getting back the extra xl_info bit. In any case the archiver could look for XLOG_BACKUP_END records if it thought it was worth the trouble to do so. Bump XLOG_PAGE_MAGIC since this is effectively a change in WAL format. http://git.postgresql.org/pg/commitdiff/2dd9322ba6eea76800b38bfea0599fbc459458f2
  • Add missing 'static' qualifier. http://git.postgresql.org/pg/commitdiff/fb4bbc8113e5b5eb1233418ad1f92428339da370
  • Add SP-GiST (space-partitioned GiST) index access method. SP-GiST is comparable to GiST in flexibility, but supports non-balanced partitioned search structures rather than balanced trees. As described at PGCon 2011, this new indexing structure can beat GiST in both index build time and query speed for search problems that it is well matched to. There are a number of areas that could still use improvement, but at this point the code seems committable. Teodor Sigaev and Oleg Bartunov, with considerable revisions by Tom Lane http://git.postgresql.org/pg/commitdiff/8daeb5ddd698f661eb118f8e874e7c68cfd6ae09
  • Fix compiler warning seen on 64-bit machine. http://git.postgresql.org/pg/commitdiff/85df5dbf5ac56f75cf9e23fe4504f2e672893f30
  • Fix some long-obsolete references to XLogOpenRelation. These were missed in commit a213f1ee6c5a1bbe1f074ca201975e76ad2ed50c, which removed that function. http://git.postgresql.org/pg/commitdiff/dd45d3ad33bdb415b18ee8b37182b52c1c354cd6
  • Remove bogus entries in gist point_ops operator class. These entries could never be matched to an index clause because they don't have the index datatype on the left-hand side of the operator. (Their commutators are in the opclass, which is sensible, but that doesn't mean these operators should be.) Spotted by a test that I recently added to opr_sanity to catch exactly this type of thinko. AFAICT there is no code in gistproc.c that is specifically meant to cover these cases, so nothing to remove at that level. http://git.postgresql.org/pg/commitdiff/5577ca5bfb33bf7f31a03fc5b42a56de400e464e
  • Defend against null scankeys in spgist searches. Should've thought of that one earlier. http://git.postgresql.org/pg/commitdiff/b7a0e8fb4d6fafcd30555e4ddf18e77e138ec3d0
  • Replace simple constant pg_am.amcanreturn with an AM support function. The need for this was debated when we put in the index-only-scan feature, but at the time we had no near-term expectation of having AMs that could support such scans for only some indexes; so we kept it simple. However, the SP-GiST AM forces the issue, so let's fix it. This patch only installs the new API; no behavior actually changes. http://git.postgresql.org/pg/commitdiff/3695a555136a6d179cac8ae48d5f90171d5b30e9

Andrew Dunstan a poussé :

Peter Eisentraut a poussé :

Robert Haas a poussé :

  • Fix typo. http://git.postgresql.org/pg/commitdiff/f6835ea90ac4b6b87fcf9f042959756c246f8fbe
  • Don't leave regress_test_role_super lying around. Fixes an oversight in commit fc6d1006bda783cc002c61a5f072905849dbde4b. Noted by Tom Lane. http://git.postgresql.org/pg/commitdiff/d039fd51f79e9ddde4d692d2b396bdf5722b4c4e
  • Improve behavior of concurrent ALTER <relation> .. SET SCHEMA. If the referrent of a name changes while we're waiting for the lock, we must recheck permissons. We also now check the relkind before locking, since it's easy to do that long the way. Patch by me; review by Noah Misch. http://git.postgresql.org/pg/commitdiff/1da5c119594e4fb07fb6a2c57f66642fa5e966fb
  • Improve behavior of concurrent rename statements. Previously, renaming a table, sequence, view, index, foreign table, column, or trigger checked permissions before locking the object, which meant that if permissions were revoked during the lock wait, we would still allow the operation. Similarly, if the original object is dropped and a new one with the same name is created, the operation will be allowed if we had permissions on the old object; the permissions on the new object don't matter. All this is now fixed. Along the way, attempting to rename a trigger on a foreign table now gives the same error message as trying to create one there in the first place (i.e. that it's not a table or view) rather than simply stating that no trigger by that name exists. Patch by me; review by Noah Misch. http://git.postgresql.org/pg/commitdiff/74a1d4fe7cc092076806767925d6f34ea347efde
  • Various micro-optimizations for GetSnapshopData(). Heikki Linnakangas had the idea of rearranging GetSnapshotData to avoid checking for sub-XIDs when no top-level XID is present. This patch does that plus further a bit of further, related rearrangement. Benchmarking show a significant improvement on unlogged tables at higher concurrency levels, and mostly indifferent result on permanent tables (which are presumably bottlenecked elsewhere). Most of the benefit seems to come from using the new NormalTransactionIdPrecedes() macro rather than the function call TransactionIdPrecedes(). http://git.postgresql.org/pg/commitdiff/0d76b60db4684d3487223b003833828fe9655fe2

Bruce Momjian a poussé :

Michael Meskes a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Simon Riggs sent in two revisions of a patch which introduces regular keepalives from WALsender to WALreceiver, using a new protocol message 'k'.
  • KaiGai Kohei sent in another revision of the patch intended to plug certain class of information leaks in VIEWs.
  • Jeff Davis and Alexander Korotkov traded patches to clean up some infelicities in range types.
  • Shigeru HANADA and Etsuro Fujita traded revisions of the patch to make it possible to collect statistics on CSV foreign tables.
  • Peter Eisentraut sent in another revision of the patch adding type privileges.
  • Marti Raudsepp sent in another revision of the patch to cache the results of functions with stable arguments.
  • Brendan Jurd sent in a patch to add arithmetic operators for the macaddr type.
  • Alexander Shulgin and Greg Smith traded patches to implement a URI syntax for PostgreSQL connection strings in libpq.
  • Robert Haas sent in another revision of the patch to allow taking fewer snapshots per query.
  • Greg Smith and Magnus Hagander traded revisions of a patch to allow users to kill their own queries.
  • Pavel Stehule sent in four more revisions of the patch to add a CHECK FUNCTION statement.
  • Andrew Dunstan sent in a patch to make libpgport build dynamically rather than statically.
  • Shigeru HANADA sent in another flock of patches intended both to enable a PostgreSQL foreign data wrapper along with some new push-down capabilities for foreign data wrappers in general to make the aforementioned useful.
  • Peter Geoghegan sent in another revision of the patch to alter pg_stat_statements to allow query tree based normalization.
  • Robert Haas sent in two more revisions of the patch to store hot members of PGPROC out of the band.
  • Robert Haas sent in another revision of the Flexlocks patch.
  • Simon Riggs sent in another revision of a patch to fix some PGPROC race conditions.
  • Heikki Linnakangas sent in a patch to move more work outside WALInsertLock, which bottlenecks operations when >1 core is available.
  • Alvaro Herrera sent in another revision of the patch to make it possible to make CHECK constraints not be inherited by child tables in a table inheritance hierarchy.
  • Robert Haas sent in another revision of the patch to add JSON as a first-class data type.
  • Lionel Elie Mamane sent in a patch to build libpq with Mozilla LDAP instead of OpenLDAP.
  • Phil Sorber sent in a WIP patch which improves relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation.
  • David Fetter sent in a patch to add optional page checksums.
  • Dimitri Fontaine sent in a patch to make it possible to see and set EXTENSION dependencies functionally.

par N Bougain le dimanche 25 décembre 2011 à 23h36

samedi 17 décembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 11 décembre 2011

Nouvelles versions correctives 9.1.2, 9.0.6, 8.4.10, 8.3.17 and 8.2.23. Il s'agit de la dernière publication officielle de la série 8.2. Si vous utilisez la réplication intégrée, il est conseillé de mettre à jour dès que possible : http://www.postgresql.org/about/news/1366/

FOSDEM 2012 - Devroom PostgreSQL : l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en décembre

PostgreSQL Local

  • L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
  • FOSDEM 2012 - Devroom PostgreSQL : l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/
  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

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)

Patches

La section des patchs ne sera pas publiée cette semaine. Si vous souhaitez son retour, veuillez contacter david AT fetter DOT org, en particulier si vous avez des ressources -du temps par exemple- à donner au projet.

par N Bougain le samedi 17 décembre 2011 à 18h41

lundi 12 décembre 2011

Dimitri Fontaine (2nd Quadrant)

Pourquoi choisir PostgreSQL plutôt que SQL Server?

Un article récent en anglais propose dix bonnes raisons de choisir PostgreSQL plutôt que SQL Server dans le cadre d’un nouveau projet, ce qui nous offre une belle occasion de revenir sur notre publication précédente qui ciblait la migration vers PostgreSQL. Nous pouvons donc cette fois nous intéresser de plus prêt aux particularités de PostgreSQL !

La dizaine de points choisis par Jeremiah Peschka dans l’article précédent s’éloigne parfois de la liste que j’aurais moi-même établie, aussi vais-je éviter de vous faire une traduction simple du contenu anglais mentionné. Plusieurs points méritent tout de même d’être mentionnés ici.

PostgreSQL stabilise et distribue une nouvelle version majeure de sa base de données chaque année. Le cycle de développement actuel (que nous connaissons bien ici, pour y participer) est composé de deux grandes étapes, six mois de développement suivis de six mois de relectures, tests, correctifs, polissages et améliorations de la documentation.

Cela permet d’obtenir de très bonnes versions point zéro autour du mois de septembre chaque année. Cela n’a pas toujours été le cas dans la gestion du projet PostgreSQL, mais ce modèle a été mis en place de manière professionnelle sur plusieurs années afin de pouvoir mieux accepter les améliorations apportées par plus de deux cents développeurs en moyenne.

Bien sûr, très peu de projets industriels peuvent se permettre de revoir leur architecture, leurs procédures et leur intégration SQL chaque année, et même dans le milieu très dynamique des services web cela n’arrive quasiment pas.Aussi les versions de PostgreSQL sont-elles maintenues pendant au moins cinq ans, les versions courantes de PostgreSQL sont donc au nombre de 5 à 7 selon les moments de l’année.

L’avantage n’est donc pas de pouvoir mettre à jour chaque année, mais bien de pouvoir en toute sérénité choisir la date de mise à jour de la version de PostgreSQL selon son propre calendrier de maintenance et d’évolutions avec la garantie de pouvoir à tout moment choisir une nouvelle version vieille au maximum d’un an.

 

Il existe ensuite de nombreux points techniques donnant un avantage très net à PostgreSQL, soit qu’il s’agisse d’innovations technologiques issues de la recherche, telles les « Serializable snapshot isolation » (ou SSI), ou bien la réplication synchrone contrôlable pour chaque transaction ; ou bien qu’il s’agisse de supports avancés aux développeurs, telles les recherches des plus proches voisins via un parcours d’index, les requêtes avancées en écriture (comparable au pipe sous unix, mais avec des ordres de lecture ou d’écriture SQL), ou bien le support avancé des types de données souvent utilisés.

Ces capacités avancées, cette souplesse d’utilisation et de paramétrage dynamique, associés à des caractéristiques de performance époustouflantes (dans la plupart des usages, dont très certainement le vôtre), la qualité de sa documentation, tout cela donne un avantage crucial à PostgreSQL : une réduction imbattable des coûts de développement et de maintenance de vos logiciels.

Vos développeurs peuvent écrire des requêtes complexes avec la garantie d’obtenir le bon résultat même dans une utilisation concurrente, faire des calculs de dates dans des timezones différentes et au milieu du changement d’heure (tous les mois ne font pas le même nombre de jours, tous les jours ne font pas 24 heures non plus, PostgreSQL le sait), exprimer des contraintes avancées (le même client ne doit pas réserver deux voitures différentes dans le même créneau horaire) qui doivent fonctionner systématiquement et sans verrous, etc.

Bénéficier de PostgreSQL pour résoudre cet ensemble de problème permet de ne pas avoir à les résoudre à nouveau dans votre application (quel jour serons-nous dans trois mois ? SELECT to_char(date 'today' + 3 * interval '1 month', 'Day'); est sûrement plus facile à utiliser que n’importe quel autre code, les développeurs lisant cela seront sûrement d’accord). Le temps passé à exploiter la documentation de PostgreSQL est un investissement facile à réutiliser et à rentabiliser, et c’est du temps de gagné dans le développement de ce qui fait la valeur ajoutée de votre application.

La raison pour laquelle nous aimons tant vanter les qualités techniques de PostgreSQL est simple. Il s’agit là d’un formidable levier vous permettant de produire des application meilleures car plus simple à développer, à faire évoluer, à maintenir, déployer et administrer.

Bien évidemment, tout cela sans s’acquitter de coûts de licence appliqués par serveur ou qui dépendent de la capacité et du nombre d’installations dont vous avez besoin pour déployer une architecture. Mettre en place une solution tolérante aux pannes, de la répartition de charge pour vos rapports hebdomadaires, des instances de tests ou d’exports de données devient une décision plus facile à prendre car elle ne dépend pas des coûts de licence.

Il reste à former une équipe compétente, ce qui à mon sens est une bien meilleure utilisation de votre budget, et ce qui bien souvent représente un coût moins élevé que les licences dépensées en pure perte… dès lors que vous pouvez obtenir le même service à moindre coût. Nous pouvons vous aider à déterminer si PostgreSQL est le moteur de bases de données le mieux adapté à votre projet.

par Dimitri Fontaine le lundi 12 décembre 2011 à 13h58

Christophe Chauvet

Connaitre la taille d'un base de données PostgreSQL

Pour connaitre la taille d'un base de données il faut utiliser la fonction pg_database_size

production=# select pg_database_size('production');
 pg_database_size
------------------
        513343780
(1 ligne)

Cette taille est donnée en octets, pour avoir une meilleur représentation en Méga ou Giga, il faut utiliser la fonction pg_size_pretty

production=# select pg_size_pretty(pg_database_size('production'));
 pg_size_pretty
----------------
 490 MB
(1 ligne)

Ensuite si l'on souhaite connaître la taille d'un table il faut utiliser la fonction pg_relation_size.

production=# select pg_size_pretty(pg_relation_size('res_partner'));
 pg_size_pretty
----------------
 152 kB
(1 ligne)

Si l'on souhaite également avoir la place prise par les indexes, il faut utiliser la fonction pg_total_relation_size

production=# select pg_size_pretty(pg_total_relation_size('res_partner'));
 pg_size_pretty
----------------
 528 kB
(1 ligne)

par Christophe Chauvet le lundi 12 décembre 2011 à 11h30

samedi 10 décembre 2011

Guillaume Lelarge

Nouvelles versions mineures, mise à jour de la traduction française

Contrairement à mon habitude, les manuels français de PostgreSQL n'ont été mis à jour que maintenant, soit cinq jours après la sortie des versions. Pour me faire pardonner, j'ai enfin corrigé le problème de la recherche dans la documentation de la version 9.1 (merci à Thomas pour l'info).

J'allais oublier... la documentation de la 8.2 n'a pas disparu. Elle est juste partie rejoindre les documentations des versions obsolètes.

par Guillaume Lelarge le samedi 10 décembre 2011 à 16h01

vendredi 9 décembre 2011

Actualités PostgreSQL.fr

Mises à jour et Fin de la version 8.2

Bonjour,

Le PostgreSQL Global Development Group (PGDG) a publié lundi 5 décembre des mises à jour sur toutes les branches actives du SGBD PostgreSQL, c'est à dire les versions 9.1.2, 9.0.6, 8.4.10, 8.3.17 and 8.2.23.

Les utilisateurs des fonctionnalités concernées par ces mises à jours, notamment la réplication binaire, doivent mettre à jours leurs instances PostgreSQL dès que possible.

Ceci est également la dernière mise à jour de PostgreSQL 8.2, qui est désormais en fin de vie (en anglais : "End-Of-Life" ou "EOL"). Les utilisateurs de la version 8.2 doivent planifier une montée de version de leurs instances PostgreSQL et migrer vers la version 8.3 ou supérieure dans les prochains mois. Pour plus d'information, consulter la Politique de support des Versions :

http://wiki.postgresql.org/wiki/Pos...

Les fonctionnalités affectées par cette mise à jour sont notamment : la réplication binaire et le Hot Standby, les indexes GIN, l'extension citext, le tri dans les fonctions de fenêtrage, l'intégrité référentielle par les clés étrangères, le PL/perl, et la gestion des extensions en général... Les utilisateurs de cette fonctionanlités doivent appliquées cette mise à jour sur le champ.

Cette publication contient 52 corrections pour la version 9.1, et un nombre inférieur de corrections pour les versions plus anciennes, notamment :

  • correction de bugs dans la vue information_schema.referential_constraints view * ;
  • correction des collationnements pour les colonnes citext et les index associés * ;
  • prévention d'un crash possible lors d'une jointure avec une fonction scalaire ;
  • prévention d'une corruption de données transitoire des index GIN après un crash ;
  • prévention d'une corruption de données sur les colonnes TOAST lors de copie de données ;
  • correction d'échecs lors du démarrage d'un serveur en lecture seule ;
  • correction d'un autre bug concernant le message "variable not found in subplan target list" ;
  • correction d'un bug sur le tri des expressions d'agrégats dans les fonctions de fenêtrage ;
  • correction de plusieurs bugs sur pg_upgrade ;
  • modification de l'ordre de création d'une clé étrangère pour un meilleur support des clés s'auto-référençant * ;
  • correction de plusieurs bugs sur l'ordre CREATE EXTENSION ;
  • ajout d'un code assurant que le type de retour et la donnée renvoyée soient en accord avec PL/perl ;
  • ajout d'un code assurant que les chaînes en PL/perl sont toujours en UTF-8 ;
  • correction de bugs sur les différentes extensions ;
  • mise à jour de la base de données des fuseaux horaires.

Les modifications marquées avec une étoile entre crochets (*) nécessitent des étapes supplémentaires, après mise à jour, pour corriger les problèmes décrits. Voir les notes de versions de chaque branche pour une liste complète des modifications avec des détails sur les correctifs et les étapes à suivre.

Comme pour les autres versions mineures, les utilisateurs ne doivent pas nécessairement sauvegarder puis recharger leur base de données pour mettre à jour. Arrêtez PostgreSQL, mettez à jour les binaires et relancez PostgreSQL.

Téléchargez les nouvelles versions maintenant sur :

Code source:

Paquets binaires:

La version originale de ce message est disponible ici : http://www.postgresql.org/about/new...

par daamien le vendredi 9 décembre 2011 à 09h29

mardi 6 décembre 2011

Actualités PostgreSQL.fr

Premiers pas avec Postgresql

I Introduction

A. Pourquoi ce document?

J'ai commencé à développer sous PostgreSQL assez récemment après une longue expérience sous Oracle. La documentation générale de PostgreSQL est excellente, et très riche, mais j'avais besoin d'un document plus léger expliquant la procédure d'installation sur différents systèmes et comment démarrer (créer un cluster, configurer les connexions), ainsi que des informations sur ce qu'on pouvait faire avec PostgreSQL. Je ne l'ai pas trouvé. Après quelques mois d'utilisation, je me suis rendu compte que les problèmes des débutants étaient toujours les mêmes. Ainsi, j'ai compilé mes notes des débuts et ce que j'ai appris depuis dans ce document. Voici le résultat, en espérant qu'il vous aide à débuter et qu'il vous encourage à continuer avec PostgreSQL.

B. À qui s'adresse ce document?



Ce document a pour but de vous aider à installer PostgreSQL sous Windows ou sous Linux, et à commencer à développer.

Il est écrit pour vous faire gagner du temps dans vos premiers pas avec PostgreSQL, tout en vous expliquant les points importants afin que vous puissiez progresser par vous-même. Il s'adresse donc principalement aux développeurs d'applications, afin de leur permettre de découvrir ce puissant moteur sur une petite base de test, ou aux personnes qui débutent complètement avec PostgreSQL. Vous n'aurez pas besoin de connaissances système avancées pour suivre ce document.

Une fois que vous aurez terminé la lecture de ce document, vous pourrez continuer par la lecture de la documentation officielle pour apprendre à administrer PostgreSQL ou devenir un développeur aguerri. La dernière section de ce document vous donne les liens et références nécessaires pour continuer à progresser. Parfois les informations ne sont volontairement pas complètes, et lorsque la documentation de référence est plus claire et précise que ce qui aurait pu être fait ici, les liens sont fournis vers la documentation française.

Ce document a été écrit initialement pour la version 8.3, puis mis à jour pour la version 9.0 (voir le chapitre sur les versions).

Avertissement : ce document n'est en aucun cas un document sur le tuning de la base. Il n'est pas fait non plus pour vous apprendre à administrer une base de production.

II Présentation de PostgreSQL

PostgreSQL est un moteur de bases de données relationnelle. C'est un moteur adapté à des bases métier, donc riche en fonctionnalités et puissant. Son installation est cependant plutôt simple. Il faut juste comprendre quelques principes de base (ce que cette présentation s'efforce de faire)

Si vous ne connaissez pas les principes relationnels ou le SQL, le mieux est de vous procurer un bon ouvrage sur le sujet. L'article de Wikipedia peut être une bonne introduction (http://fr.wikipedia.org/wiki/SQL), et donne de nombreuses références. Le tutoriel de la documentation PostgreSQL peut également vous rendre service si vous avez besoin de vous rafraîchir la mémoire : http://docs.postgresqlfr.org/9.0/tutorial-sql.html

A. Licence

La licence de PostgreSQL est une licence de type BSD, ce qui permet son utilisation sans restriction, dans un logiciel libre ou propriétaire. C'est un avantage certain, car cela permet par exemple d'utiliser PostgreSQL comme base de données pour un logiciel propriétaire.

PostgreSQL est un projet indépendant. Il n'est détenu par aucune entreprise. La communauté PostgreSQL est très réactive (allez voir les mailings-lists si vous voulez vérifier). De nombreuses entreprises soutiennent et participent également au développement de PostgreSQL.

B. Caractéristiques et fonctionnalités :

PostgreSQL comporte de nombreuses fonctionnalités intéressantes. Parmi celles-ci, on peut citer par exemple : moteur transactionnel respect des normes SQL MVCC (mécanisme permettant une concurrence efficace sans verrouiller les enregistrements pour assurer l'isolation des transactions) procédures stockées dans de nombreux langages triggers réplication maître-esclaves en continu par application des journaux binaires (archives WAL), esclaves accessibles en lecture.

PostgreSQL est conçu pour être robuste (aucune version ne sort sans avoir subi une suite extensive de tests) et peut supporter des volumes importants de données (ainsi par exemple Météo France gère une base de 3,5To).

PostgreSQL est conçu pour pouvoir supporter des extensions. Des extensions et outils sont disponibles pour compléter le moteur, par exemple :

  • PostGis : moteur de données spatiales.
  • Slony : réplication maître-esclaves.
  • Et de nombreux autres.

III Installation

Avant de passer aux procédures d'installation proprement dites, il est nécessaire de comprendre certaines notions fondamentales.

A. Vocabulaire

1. Base

Une base est un ensemble structuré de données. On utilise généralement une base de donnée par application. Pour pouvoir créer une base de données, vous devez disposer d'un cluster de bases de données.

2. Cluster (ou grappe de base de données)

Un cluster est un ensemble de bases de données qui partagent les mêmes ressources (processus, mémoire, disque...) .

3. Schéma

Un schéma est un espace de nommage au sein d'une base de données.

B. Principes de base

1. Comptes système

Les processus de PostgreSQL utilisent un compte système. Généralement c'est le compte postgres qui est utilisé pour cela, sauf si vous avez installé PostgreSQL sur votre compte (voir la partie compilation).

2. Rôles

Les droits de la base de données sont gérés par des rôles. Avant de pouvoir vous connecter à la base de données, le rôle que vous utilisez doit avoir les autorisation nécessaires.

http://docs.postgresql.fr/9.0/user-manag.html

À retenir: les comptes systèmes et les rôles de base de données sont distincts! Même s'il y a des possibilités de mapping entre les deux (cf. paragraphe sur pg_hba.conf) La confusion entre ces 2 notions est une des causes fréquentes d'erreurs et de problèmes d'installation pour les débutants.

3. Versions (mineures/majeures)

Les versions majeures comprennent le chiffre avant le point et un chiffre après. Exemple : 8.2 et 8.3 sont des versions majeures différentes. Les versions mineures incrémentent la 3ème partie : exemple : 8.3.7 Pour changer de version mineure, il suffit de mettre à jour le moteur. Mais pour changer de version majeure, il est nécessaire de décharger puis recharger les données.

Plus d'informations ici : http://www.postgresql.org/support/versioning

4. Client/serveur

PostgreSQL est une application client/serveur. Le serveur gère les fichiers de la base de données, accepte les connexions des clients, et effectue les opérations demandées par les clients (requêtes...) Le client peut prendre de nombreuses formes. Il existe par exemple un client en ligne de commande (psql), des clients graphiques (par exemple pgAdmin3)... Le client peut être sur la même machine que le serveur, ou bien communiquer avec lui par le réseau.

5. Processus serveur

Sous Windows, le serveur PostgreSQL tourne en tant que service. Sous Linux, ce sont des démons système qui effectuent ces tâches. (si vous êtes curieux, vous pouvez aller voir cet article : http://dalibo.org/glmf112_les_processus_de_postgresql) Il ne faut pas arrêter les processus du serveur n'importe comment. Pour arrêter le serveur, il faut utiliser les outils fournis (voir la section sur l'arrêt et le démarrage du serveur). NB : par défaut, PostgreSQL est configuré pour écouter sur le port 5432. Les outils se connectent par défaut sur ce port : pensez à cela si vous devez modifier ce paramètre.

6. Module de contribution

Ce sont des extensions intéressantes, maintenues par le projet, mais non intégrées au coeur du moteur. Exemples :

  • adminpack (fonctions supplémentaires, utilisées par les outils d'administrations comme pgAdmin3)
  • pg_buffercache (pour savoir ce qui est présent dans le cache)
  • pg_freespacemap : donne la liste des blocs vides et partiellement vides des tables et index (quantité d'espace libre dans chaque objet de la base)
  • pgcrypto : fonctions de cryptographie

C. Exemple

Pour l'installation et la suite, nous prendrons l'exemple de la création d'une base de données mabase, qui sera utilisée et gérée par un utilisateur tom.

D. Sous Windows

À partir de la version 8.0, PostgreSQL fonctionne nativement sous Windows (Windows XP, Windows 2000, Windows 2003, Vista, Windows 2008...). Malgré tout, seules les versions à partir de la 8.2 sont supportées sous Windows. Il s'installe en tant que service.

NB : si vous regardez dans la liste des processus, plusieurs processus postgres sont présents. Gardez à l'esprit que la mémoire est partagée entre ces processus : la mémoire utilisée par PostgreSQL est donc inférieure à la somme de la mémoire utilisée par chaque processus qui est affichée dans le gestionnaire de tâches...

1. Où trouver PostgreSQL pour Windows?

Vous pouvez trouver deux types d'installeurs pour Windows : l'installeur "en un clic", ou l'installeur "pgInstaller". Le premier est créé par EnterpriseDB, le seconde par la communauté. Vous les trouverez à partir d'ici : http://www.postgresql.org/download/windows "pgInstaller" n'est disponible que pour les versions 8.2 et 8.3, le document détaille donc le processus d'installation pour l'installeur «en un clic ». NB: il est possible de récupérer les binaires sans l'installeur (pour utilisateurs avancés uniquement), ou de faire une installation silencieuse (voir sur le site de EnterpriseDB)

2. Installation

Lancez l'installeur (pour Postgresql 9.0, le fichier s'appelle : postgresql-9.0.0-1-windows.exe )

NB: L'installeur logue toutes ses actions dans un fichier install-postgresql.log qui est dans le répertoire %TEMP% de Windows. En cas de problème, consulter ce fichier.

3_repertoire.jpg

Le répertoire est celui où vont s'installer le programme serveur (postgres.exe) et les outils client (psql, pgdump...), ainsi que la documentation, etc...

L'installeur ne permet actuellement pas d'installer les outils client et le serveur séparément.

4_donnees.jpg

L'installeur demande ensuite où sera créé le cluster de données. Il sera par la suite toujours possible de créér d'autres cluster avec l'outil initdb.

5_mot_passe.jpg

L'installeur demande le mot de passe de l'utilisateur postgres. Attention, en réalité ceci recouvre 2 notions différentes : un utilisateur du système d'exploitation, celui sur le compte duquel fonctionnent les programmes du serveur, le super-utilisateur de base de données. Ils peuvent très bien avoir des noms et des mots de passe différents, mais pour cet installeur, il a été choisi de donner le même nom et le même mot de passe.

Si l'utilisateur postgres du système d'exploitation existe déjà, il faut donner le mot de passe existant. Si vous l'avez oublié, vous pouvez le changer dans une console avec la commande net user : net user postgres <motdepasse>

Attention à ne pas mettre un mot de passe trivial à l'utilisateur postgres (c'est encore plus important si vous autorisez les connexions à partir du réseau!). Évitez également de lui donner le même mot de passe que celui de l'utilisateur système postgres. En effet, l'utilisateur postgres dispose de tous les droits sur le cluster.

6_port.jpg

Par défaut, le port sur lequel le serveur attend les connexions est le port 5432. Vous pouvez changer le numéro de port d'écoute. Attention dans ce cas à configurer correctement vos clients (JDBC, etc...)

Remarque : par défaut, postgres n'acceptera pas les connexions à partir du réseau. Ceci est parfait sur un poste de développement autonome, mais pas pour un serveur. Cela pourra être modifié par configuration.

7_locale.jpg

La locale définit le comportement du cluster pour les opérations de tri (ordre alphabétique) … Par défaut, c'est celle du système qui est utilisée, mais vous pouvez en préférer une autre.

8_pret.jpg

Si vous êtes certain(e) du paramétrage, vous pouvez cliquer sur « Suivant».

9_fin.jpg

L'installation est terminée. Si vous souhaitez installer des modules complémentaires (phppgAdmin, Slony...), lancez l' outil Stackbuilder.

110_utilisation_flou.jpg

L'installation sous Windows est prête à être utilisée. Dans le menu démarrer, vous pouvez retrouver tous les outils utiles pour gérer le serveur.

Si vous avez conservé les options par défaut, les fichiers du cluster se trouvent dans C:\Program Files\PostgreSQL\9.0, et vous trouverez l'outil pour désinstaller dans le même répertoire.

NB : notes sur la console Windows et psql La console Windows est par défaut dans un encodage compatible DOS (par exemple CP850). Lorsque vous démarrerez psql pour la première fois, vous aurez le message d'avertissement suivant :

Attention : l'encodage console (850) diffère de l'encodage Windows (1252).
Les caractères 8 bits peuvent ne pas fonctionner correctement.
Voir la section « Notes aux utilisateurs de Windows » de la page
référence de psql pour les détails.

Il est recommandé de modifier l'encodage de la console, Pour éviter cela, vous pouvez éditer le fichier C:\Program Files\PostgreSQL\9.0\scripts\runpsql.bat en ajoutant la ligne :

chcp 1252

avant le lancement de psql.

Remarque importante : si vous avez installé PostgreSQL sur un poste de travail (dans le but par exemple de l'évaluer ou de vous familiariser avec lui), vous avez maintenant une installation qui fonctionne « à la sortie de la boîte », et vous pouvez commencer à l'utiliser via l'outil pgAdmin (crééer des bases, etc...). Mais si vous souhaitez autoriser des connexions distantes, il est indispensable de lire la suite du document. Il apporte également des informations qui pourraient vous être utiles (emplacement et rôle des différents répertoires...) même si vous utilisez peu les outils en ligne de commande. Vous pouvez maintenant passer à la section « après l'installation » si vous le souhaitez.

IV Après l'installation

Dans toute la suite du document, nous supposons que l'utilisateur système sous lequel PostgreSQL a été installé est postgres. Si ce n'est pas le cas, remplacez par l'utilisateur qui démarre le serveur. Conseil : avant toute modification de fichier de configuration, pensez à sauvegarder la version initiale du fichier! Une erreur est si vite arrivée...

A. Processus et emplacement des fichiers.

L'emplacement des fichiers de configuration et des fichiers du cluster dépend de votre distribution. Le répertoire contenant les fichiers du cluster est couramment appelé PGDATA (du nom de la variable d'environnement correspondante). Par exemple : /var/lib/pgsql/data (Linux) ou C:\Program Files\PostgreSQL\9.0\data (Windows) Normalement, le fichier postgresql.conf est dans le répertoire du cluster. Cependant, cela peut être autrement (sur Debian, tous les fichiers de configuration doivent être dans /etc) Voici un moyen de retrouver leur emplacement sous Linux ou Unix si vous l'avez oublié. Liste des processus nommés "postgres" : (exemple sur une Debian):

flo:~# ps -ef | grep postgres | grep -v grep
postgres  2797     1  0 06:14 ?        00:00:00 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c config_file=/etc/postgresql   /9.0/main/postgresql.conf
postgres  2798  2797  0 06:14 ?        00:00:00 postgres: logger process                                                                                        
postgres  2800  2797  0 06:14 ?        00:00:00 postgres: writer process                                                                                        
postgres  2801  2797  0 06:14 ?        00:00:00 postgres: wal writer process                                                                                    
postgres  2802  2797  0 06:14 ?        00:00:00 postgres: autovacuum launcher process                                                                           
postgres  2803  2797  0 06:14 ?        00:00:00 postgres: stats collector process                                                                               
flo:~#

Voyez que le processus 2797 est le père de tous les autres :

postgres  2797     1  0 06:14 ?        00:00:00 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c config_file=/etc/postgresql/9.0/main/postgresql.conf

le chemin derrière le -D est l'emplacement du cluster. Celui derrière le -c l'emplacement du fichier de configuration.

config_file=/etc/postgresql/9.0/main/postgresql.conf

Normalement, les autres fichiers de configuration du cluster (pg_hba.conf, pg_ident.conf) sont dans le même répertoire .

/usr/lib/postgresql/9.0/bin/postgres

est l'emplacement des binaires.

Arborescence du répertoire du cluster:

flo:/var/lib/postgresql/9.0/main# ls -l
total 48 
drwx-- 11 postgres postgres 4096 mai 10 15:19 base 
drwx--  2 postgres postgres 4096 mai 10 18:29 global
drwx--  2 postgres postgres 4096 avr  4 19:58 pg_clog
drwxr-xr-x  2 postgres postgres 4096 mai 10 08:15 pg_log
drwx--  4 postgres postgres 4096 avr  4 19:58 pg_multixact
drwx--  2 postgres postgres 4096 avr  4 19:58 pg_subtrans
drwx--  2 postgres postgres 4096 avr  4 19:58 pg_tblspc
drwx--  2 postgres postgres 4096 avr  4 19:58 pg_twophase
-rw---  1 postgres postgres    4 avr  4 19:58 PG_VERSION
drwx--  3 postgres postgres 4096 avr  4 19:58 pg_xlog
-rw---  1 postgres postgres  133 mai 10 08:15 postmaster.opts
-rw---  1 postgres postgres   54 mai 10 08:15 postmaster.pid
lrwxrwxrwx  1 root     root       31 avr  4 19:58 root.crt -> /etc/postgresql-common/root.crt

Quelques sous-répertoires et fichiers :

  • base : répertoire des fichiers de base de données
  • pg_log : log de la base de données (c'est le seul répertoire du cluster où vous pouvez supprimer des fichiers!)
  • pg_clog et pg_xlog : commit log (état des transactions) et répertoire des fichiers WAL (Write Ahead Log, utilisé pour la durabilité ).
  • postmaster.pid : fichier verrou utilisé pour éviter que plusieurs instances ne soient actives sur le même répertoire de données.

Attention : le contenu de pg_clog et pg_xlog ne doit pas être supprimé!

B. Changer le mot de passe de l'utilisateur système postgres

À moins que vous n'ayez compilé les sources pour utiliser PostgreSQL sur votre compte utilisateur, un utilisateur postgres a été créé sur votre système. Afin de pouvoir l'utiliser, vous devez changer le mot de passe de cet utilisateur. Pour cela, sous Linux, connectez-vous en tant que root et exécutez la commande 'passwd postgres'. (ne pas utiliser un mot de passe trivial!)

C. Créer un cluster de base de données.

Avec certaines distributions (Redhat, Debian), un cluster est créé par défaut à l'installation des paquets. De même pour l'installation sous Windows. Si vous êtes dans un autre cas de figure, il vous faudra donc en créer un. Pour cela, utilisez la commande initdb.

D. Autoriser les connexions

L'installation de PostgreSQL positionne des valeurs par défaut dans les fichiers de configuration. Après l'installation, PostgreSQL est configuré de telle sorte que les connexions ne sont pas possibles à partir du réseau. Pour autoriser des clients distants à se connecter, il faut configurer deux fichiers : postgresql.conf et pg_hba.conf.

1. Connexions réseau (postgresql.conf)

À l'installation, PostgreSQL est configuré pour n'accepter que les connexions locales (c'est le paramètre listen_addresses). Si vous souhaitez pouvoir vous connecter à partir du réseau, il faut dé-commenter le paramètre listen_addresses du fichier postgresql.conf, et préciser sur quelle(s) adresse(s) postgres accepte les connexions.

Attention : ce sont bien les adresses IP d'écoute, c'est-à-dire les adresses IP du serveur sur lesquelles le serveur PostgreSQL va écouter. Si vous précisez une adresse '*', postgres va écouter les connexions sur toutes les interfaces réseau du serveur. Si vous précisez une adresse IP, cela signifie que postgres va écouter sur l'interface réseau de votre machine qui a cette adresse IP. Si vous souhaitez n'autoriser les connexions qu'à une liste de machines ou d'adresses IP, c'est dans pg_hba.conf que vous pouvez le faire (paragraphe suivant). Pour que les paramètres soient pris en compte, il faut redémarrer le serveur PostgreSQL. Exemples : (connexion locales)

#listen_addresses = 'localhost'         # what IP address(es) to listen on;
                                       # comma-separated list of addresses;
                                       # defaults to 'localhost', '*' = all
                                       # (change requires restart)
port = 5432                             # (change requires restart)@@

(connexion sur l'adresse 192.168.0.4 et local, port 5433)

listen_addresses = '192.168.0.4, localhost'         # what IP address(es) to listen on;
                                       # comma-separated list of addresses;
                                       # defaults to 'localhost', '*' = all
                                       # (change requires restart)

port = 5432 # (change requires restart)@@

2. Authentification des clients (pg_hba.conf)

Le fichier pg_hba.conf configure les autorisations pour les bases du cluster. Chaque ligne précise une règle aidant à décider si l'utilisateur est habilité à se connecter ou non. Le fichier est lu dans l'ordre par postgres, et, dès qu'une ligne est rencontrée qui correspond au cas testé, la lecture s'arrête. Cela signifie que l'ordre des lignes est important. Sur chaque ligne est précisé le type de connexion, un nom de base de données, un nom d'utilisateur, et la méthode d'authentification. Les méthodes d'authentification les plus classiques sont : md5 (par mot de passe crypté), ident (à partir du nom d'utilisateur du système d'exploitation, non utilisable sous Windows).

Exemple :

# connection par socket Unix pour l'administration du serveur
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         postgres                               ident sameuser
# connection par socket Unix 
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   mabase      tom                                    md5
local   truc        all                                    ident sameuser
# Connexions locales en Ipv4 :
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    mabase      tom         127.0.0.1/32          md5
host    truc        all         127.0.0.1/32          md5
# Connexion distante en Ipv4 :
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
host    mabase      tom         192.168.12.10/32      md5
host    truc        all         192.168.12.10/32      md5

La première ligne : local all postgres ident sameuser signifie que, si postgres reçoit une demande de connexion sur n'importe quelle base (all) par socket Unix (local), pour l'utilisateur postgres, alors la méthode d'authentification utilisée est : ident. sameuser signifie que postgres vérifie que le nom de l'utilisateur Unix propriétaire de la socket est le même que celui utilisé pour se connecter à la base.

La ligne suivante : local mabase tom md5

signifie que, lorsque tom essaie de se connecter par socket Unix sur la base mabase, c'est l'authentification md5 qui est utilisée.

La ligne : local truc all ident sameuser

signifie que lorsque n'importe que n'importe quel utilisateur essaie de se connecter à la base truc par socket Unix, c'est l'authentification ident sameuser qui est utilisée.

La ligne :

host mabase tom 127.0.0.1/32 md5

signifie qu'une demande de connexion à partir pour la base mabase, par un utilisateur tom, en local par Ipv4 est authentifiée par md5.

La ligne :

host mabase tom 192.168.12.10/32 md5

signifie qu'une demande de connexion de l'utilisateur tom sur mabase, à partir de l'adresse 192.168.12.10 est authentifiée par md5.

On voit donc que tom est autorisé à se connecter sur la base mabase, soit par socket Unix, soit par Ipv4 en local, soit par Ipv4 à partir de : 192.168.12.10. Les autres utilisateurs (à part l'utilisateur postgres) ne peuvent se connecter que sur la base truc. Tom peut également se connecter sur la base truc, car tom fait partie de l'ensemble des utilisateurs (all). NB : CIDR est une façon de noter les ensembles d'adresses IP, avec le chiffre derrière le '/' indiquant la taille du masque en bits (ainsi un réseau de classe A est en /8, classe B, 16, classe C, 24, une IP unique /32, et tout le monde : 0.0.0.0/0 ) (voir l'article Wikipedia : http://fr.wikipedia.org/wiki/Adresse_IPv4 )

Remarques : Le fichier configure le cluster, il est donc commun à toutes les bases du cluster : attention à ne pas autoriser un utilisateur sur une base par erreur. Attention, ne surtout pas autoriser d'authentification trust ni ident par le réseau, parce que cela signifierait faire entièrement confiance au client... Si vous voulez en savoir plus sur l'authentification du client, allez voir la documentation ici : http://docs.postgresql.fr/9.0/client-authentication.html

3. Prise en compte des paramètres de configuration

Pour que PostgreSQL prenne en compte les modifications de paramètres sans redémarrer le serveur, vous avez les solutions suivantes :

  • utiliser pg_ctl reload (remplacé par pg_ctlcluster sous Debian)
  • envoyer un signal SIGHUP à postgres

Sous Windows, il est possible d'utiliser un raccourci dans le menu Démarrer (« Rechargez la configuration »).

Attention : certaines options ne sont prises en compte qu'au démarrage (voir la documentation, les commentaires de postgresql.conf ou la colonne context de la vue pg_settings)

4. Créer une base

Nous allons créer une base mabase sur le cluster, puis faire de tom le propriétaire de la base (afin qu'il puisse faire ce qu'il veut sur cette base)

postgres@flo:/etc/postgresql/9.0/main$ pg_lsclusters
Version Cluster   Port Status Owner    Data directory                     Log file
9.0 main      5432 online postgres /var/lib/postgresql/9.0/main       custom

Pour cela, lancez la commande createdb :

postgres@flo$ createdb mabase

NB : createdb lance en fait la commande CREATE DATABASE pour vous.

5. Créer un rôle et lui donner des droits sur une base

NB : les utilisateurs et les groupes sont tous gérés par des rôles.

En tant qu'utilisateur postgres, lancez psql :

postgres@flo:/usr/share/doc/postgresql-common$ psql Bienvenue dans psql 9.0.6, l'interface interactive de PostgreSQL.

Saisissez:
    \copyright pour les termes de distribution
    \h pour l'aide-mémoire des commandes SQL
    \? pour l'aide-mémoire des commandes psql
    \g ou point-virgule en fin d'instruction pour exécuter la requête
    \q pour quitter
postgres=#

Créez un rôle tom, avec les droits de login (pour qu'il ait le droit de se connecter au serveur), et le mot de passe : secret.

postgres=# CREATE ROLE tom LOGIN password 'secret';
CREATE ROLE
postgres=#

Pour que tom soit le propriétaire de mabase :

postgres=# ALTER DATABASE mabase OWNER TO tom;
ALTER DATABASE

Sortez de psql :

postgres=# \q
postgres@flo:/usr/share/doc/postgresql-common$

NB : les commandes CREATE DATABASE et CREATE ROLE (création de base et d'utilisateur) sont globales au cluster. Il est donc possible de les exécuter de n'importe quelle base.

Maintenant, l'utilisateur tom peut se connecter sur mabase : lancez psql, en précisant que vous vous connectez en tant que tom :

flo@flo:~$ psql -U tom mabase
Mot de passe pour l'utilisateur tom :
Bienvenue dans psql 9.0.6, l'interface interactive de PostgreSQL.
Saisissez:
    \copyright pour les termes de distribution
    \h pour l'aide-mémoire des commandes SQL
    \? pour l'aide-mémoire des commandes psql
    \g ou point-virgule en fin d'instruction pour exécuter la requête
    \q pour quitter
mabase=>

Remarque : il faut préciser la base! Sinon psql cherchera à se connecter à une base "tom".

Si vous souhaitez donner le droit à tom de créer des bases:

postgres=# ALTER ROLE tom CREATEDB;
ALTER ROLE
postgres=#

Pour les détails sur les droits, lisez le chapitre correspondant de la documentation : http://docs.postgresqlfr.org/9.0/privileges.html

E. Super-utilisateur

Le super-utilisateur est un utilisateur qui dispose de droits spéciaux (certaines fonctions ne sont utilisables que par un super-utilisateur). Les super-utilisateurs passent au travers des vérifications de droits. Si vous avez installé PostgreSQL en tant que root, classiquement vous avez un super-utilisateur postgres. Attention! Le super-utilisateur disposant de tous les droits, éviter de l'utiliser si ce n'est pas nécessaire, afin de limiter le risque d'erreur.

F. Je ne peux pas me connecter à la base? Que faire?

Que vérifier?

  • D'abord : lisez le message d'erreur! (ça peut suffire à trouver la solution à partir d'un bon moteur de recherche, des archives des mailing-lists ou de forums...)
  • Consultez la log (voir chapitre suivant)
  • Cherchez quels sont les clusters présents ? (sous Debian : pg_lsclusters...)
  • Vérifiez le fichier postgresql.conf (le paramètre listen_addresses est-il correct? Le port est-il celui souhaité? Le client essaie-t-il de se connecter sur le bon port?)
  • Vérifiez le fichier pg_hba.conf
  • Vérifiez le propriétaire de la base
  • Le rôle que vous utilisez a-t-il le droit de se loguer (autorisation LOGIN) ?
  • Le rôle utilisé a-t-il le droit de se connecter à la base de données (sinon utilisez GRANT CONNECT on mabase ...)

NB : vous obtenez la liste des bases d'un cluster avec la commande \l dans psql

G. Où se trouve la log ? Comment la configurer?

La configuration de la log est effectuée par le fichier postgresql.conf (voir les paramètres log_destination et log_directory) Dans une installation standard de PostgreSQL, la log se trouve dans un répertoire pg_log sous le répertoire PGDATA (répertoire du cluster). Par exemple, sous Windows :

C:\Program Files\PostgreSQL\9.0\data\pg_log



En fonction de votre utilisation (production, test, développement), vous pourrez régler les paramètres de la log. Par exemple, loguer tous les ordres SQL peut être fort utile en développement (surtout lorsque vous utilisez un ORM).

Pensez à recharger la configuration après modification.

H. Arrêter/démarrer le serveur PostgreSQL

Sous Windows : vous pouvez utiliser "stoppez le service" et "démarrez le service" dans le menu démarrer, ou bien dans un terminal, utiliser pg_ctl :

C:\Program Files\PostgreSQL\9.0\bin>pg_ctl start -D "C:\Program Files\PostgreSQL\9.0\data"
server starting

Sous Linux : c'est la commande pg_ctl (sous Debian : pg_ctlcluster ou service postresql start

sous Redhat)

V Outils

A. Outil graphique : pgAdmin3

PgAdmin3 est sans doute l'outil le plus populaire pour développer et administrer PostgreSQL. http://www.pgadmin.org/?lang=fr_FR Voici un apercu de ce à quoi il ressemble. Pour le reste, vous pourrez vous reporter à sa documentation.

pgadmin

B. psql (outil en ligne de commande)

Psql permet d'exécuter des ordres SQL sur les bases, et également des commandes de gestion et d'administration. Pour lancer psql :

1. Windows :

a) Via le menu démarrer (gère tout seul le changement d'utilisateur)

Remarque : si, à la première connexion, vous avez ce message d'avertissement :

Warning: Console code page (437) differs from Windows code page (1252)
        8-bit characters might not work correctly. See psql reference
        page "Notes for Windows users" for details.
postgres=#

reportez-vous à la partie installation sous Windows.

b) En ligne de commande dans une console :

Si vous lancez psql non pas avec le menu démarrer, mais à partir d'une console Windows, il faut être connecté en tant qu'utilisateur système postgres. Ceci est possible avec la commande runas de Windows.

runas user:postgres cmd.exe Puis modifiez la police de la console pour utiliser Lucida Console, et changez de code page :

cmd.exe /c chcp 1252

(pour la France)

Malheureusement, si votre base est en UTF8, la console Windows est incapable de gérer correctement l'affichage. Il faudra également éviter de saisir des données avec psql, et préférer pgAdmin pour cet usage (pgAdmin gère parfaitement les différents encodages).

2. Sous Linux :

psql mabase

3. Remarques :

Si vous ne précisez pas le nom de la base, psql essaie de se connecter à la base de même nom que l'utilisateur. Si vous ne précisez pas le nom d'utilisateur, c'est le nom de l'utilisateur du système qui est utilisé.

4. Commandes

Commandes psql à connaître absolument :

  • \? pour l'aide des commandes psql (si vous deviez n'en retenir qu'une)
  • \q quitter
  • \h aide des commandes sql

autres commandes intéressantes :

  • \l liste des bases de données
  • \c se connecter à une base
  • \d [nom] pour la description d'une table, d'un index, séquence, vue
  • \d liste des relations (tables, vues et séquences)
  • \i nom_fichier exécuter un fichier de commandes SQL

Attention! Pour la commande \i, les noms de fichiers sous Windows doivent utiliser le séparateur slash " / "et non antislash " \ "  . Exemple :

\i C:/tests.sql

C. phpPgAdmin

C'est un outil d'administration web pour PostgreSQL http://phppgadmin.sourceforge.net/

D. Copy

copy est un outil pour le chargement et déchargement de données en masse. Ce n'est pas une commande standard SQL. http://docs.postgresqlfr.org/9.0/sql-copy.html

VI Développement

A. SQL

Plusieurs outils permettent d'exécuter du code SQL de façon interactive : psql, pgAdmin (voir les sections qui leur sont consacrées). Vous pouvez également utiliser un outil tiers, si vous préférez...

B. Procédures stockées

L'intérêt des procédures stockées est de pouvoir exécuter des fonctions directement sur le serveur. Les procédures stockées sont efficaces et rapides, et permettent de traiter des données, soit pour consultation par un client, soit en mise à jour.

PostgreSQL vous donne le choix du langage de procédures stockées.

Vous pouvez utiliser:

  • PL/pgsql (proche de SQL, facile à utiliser, utilisable pour les triggers)
  • PL/Tcl
  • PL/Perl (pratique lorsqu'il y a des traitements de chaînes de caractères à effectuer)
  • PL/Python
  • D'autres langages ne sont pas inclus dans la distribution principale :
  • PL/Java, PL/PHP, PL/R, PL/Ruby, PL/Scheme, PL/sh
  • Vous pouvez aussi en définir un vous-même...

C. JDBC

Le pilote JDBC pour PostgreSQL est un pilote natif (il est entièrement écrit en Java)

Les différentes versions du pilote JDBC sont disponibles ici (ainsi que la documentation)

http://jdbc.postgresql.org/index.html Ensuite vous avez juste à utiliser le .jar de manière classique (le mettre dans le CLASSPATH de votre application)

NB : la syntaxe de l'URL String url="jdbc:postgresql:test_conn";

L'URL a une de ces formes :

  • jdbc:postgresql:database
  • jdbc:postgresql://host/database
  • jdbc:postgresql://host:port/database

Allez voir la documentation http://jdbc.postgresql.org/documentation/83/connect.html pour plus de détails.

Quel driver prendre ?

Normalement, la dernière version du driver devrait vous convenir (elle est compatible avec toutes les versions supportées de PostgreSQL). Mais il y en a 2 variétés : la JDBC3, à préférer pourt les JVM 1.4 et 1.5, et la JDBC4, pour la JVM 1.6. Plus de précisions et une matrice de compatibilité sur la page de téléchargement : http://jdbc.postgresql.org/download.html

D. Autres (PERL, Python, .Net, ODBC, Tcl...)

Voir ici : http://docs.postgresqlfr.org/9.0/external-projects.html

E. A savoir !

1. Majuscules/minuscules

Le nom des objets dans les ordres SQL est converti automatiquement en minuscules. Par exemple, si vous exécutez : SELECT Id, Valeur FROM Matable; l'ordre réellement exécuté sera : SELECT id, valeur FROM matable;

mabase=> SELECT Id, Valeur FROM Matable;
 id | valeur
+
  1 | azerty
(1 ligne)
mabase=>

Si vous souhaitez utiliser la casse dans les noms d'objets (ce qui n'est pas conseillé en général), utilisez les guillemets.

Par exemple : SELECT "Id", "Valeur" FROM "Matable"; Remarquez que ce comportement est différent d'autres moteurs, qui soit passent tous les noms en majuscule, soit conservent la casse. (Le comportement standard pour un SGBD est d'ignorer la casse, ainsi il est déconseillé généralement d'utiliser des noms d'objet avec des casses différentes : si vous utilisez toujours des minuscules, le comportement sera toujours le même, quel que soit le SGBD)

2. Erreurs et transactions

Avec PostgreSQL, lorsqu'une erreur se produit dans une transaction, il n'est pas possible de l'ignorer. L'erreur doit être gérée. Sinon tous les ordres suivants sont également en erreur. De plus, à la fin de la transaction, il n'est pas possible de commiter. L'ordre COMMIT provoque en réalité un ROLLBACK.

Exemple :

mabase=> begin;
BEGIN
mabase=> insert into matable(valeur, nb) values ('c',2);
INSERT 0 1
mabase=> insert into matable(valeur, nb) values ('c',2);
ERREUR:  la valeur d'une clé dupliquée rompt la contrainte unique « u_matable »
mabase=> insert into matable(valeur, nb) values ('d',2);
ERREUR:  la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc
de la transaction
mabase=> commit;
ROLLBACK
mabase=> select valeur, nb from matable;
 valeur | nb
+
 a      |  2
 b      |  2
(2 lignes)
mabase=>

3. Savepoints

Les savepoints ne sont pas spécifiques à PostgreSQL. Mais c'est une fonctionalité SQL trop peu connue, et pourtant extrêmement utile, dans le cas de traitements lourds.

Un savepoint sert à marquer un point de reprise dans un traitement. Lorsque vous avez à effectuer un traitement long (par exemple lorqu'un programme doit mettre à jour tout un ensemble de données les unes après les autres), vous pouvez mettre des savepoints à intervalles réguliers. Lorsqu'une erreur se produit, vous faites en sorte que le programme effectue un ROLLBACK TO SAVEPOINT vers un point de sauvegarde où l'état de vos données est cohérent (généralement le dernier point de sauvegarde). Ensuite vous pouvez annuler le traitement (après par exemple pris la précaution de loguer les événements...)

L'intérêt est que seul les traitements effectués après le point de sauvegarde sont perdus. Cela évite à votre programme de faire un ROLLBACK sur l'ensemble du traitement! Votre programme peut ainsi effectuer des traitements partiellement.

4. DDL dans les transactions!

Une des fonctionnalités les plus épatantes de PostgreSQL est la possibilité d'inclure des ordres DDL dans des transactions.

Exemple :

Dans une transaction, on crée une table "test", puis une table "matable". La création de "matable" échoue (la table existe déjà). On fait un rollback sur la transaction : la table "test" n'existe pas.

mabase=> BEGIN;
BEGIN
mabase=> CREATE TABLE test (
    id serial NOT NULL,
    valeur character varying(20) NOT NULL);
NOTICE:  CREATE TABLE créera des séquences implicites « test_id_seq » pour la colonne serial « test.id »
CREATE TABLE
mabase=> ALTER TABLE test ADD CONSTRAINT pk_test PRIMARY KEY (id);
NOTICE:  ALTER TABLE / ADD PRIMARY KEY créera un index implicite « pk_test » pour la table « test »
ALTER TABLE
mabase=> CREATE TABLE matable (
    id serial NOT NULL,
    valeur character varying(20) NOT NULL);
NOTICE:  CREATE TABLE créera des séquences implicites « matable_id_seq1 » pour la colonne serial « matable.id »
ERREUR:  la relation « matable » existe déjà
mabase=> ROLLBACK;
ROLLBACK
mabase=> \d
                 Liste des relations
 Schéma |       Nom        |   Type   | Propriétaire
+++--
 public | matable          | table    | tom
 public | matable_id_seq   | séquence | tom
 public | table_flo        | table    | flo
 public | table_flo_id_seq | séquence | flo
(4 lignes)
mabase=>

Intérêt :

On peut faire tout un ensemble de modification de façon atomique (par exemple la migration d'un schéma pour l'évolution d'une application), C'est un soulagement pour le DBA qui devra passer votre script de migration, de nuit, de savoir qu'il n'aura pas à restaurer la base en cas d'échec.

5. Count(*)

En raison de l'implémentation actuelle du MVCC, count(*) force le parcours complet de la table, ce qui est donc lent.

VII Et après?

A. Lire la documentation :

Lien vers la documentation en Français : http://docs.postgresql.fr/ En anglais : [http://www.postgresql.org/docs/ |http://www.postgresql.org/docs/|en]

B. Sites utiles :

http://www.postgresql.org/ : site officiel http://www.postgresql.fr/ : site de la communauté francophone.

C. Pour trouver de l'aide complémentaire :

La communauté PostgreSQL est très active, et vous trouverez facilement de l'aide pour les problèmes les plus simples aussi bien que pour les cas les plus tordus.

1. Listes de diffusion :

La liste francophone : http://archives.postgresql.org/pgsql-fr-generale/ Les autres : http://www.postgresql.org/community/lists/ Attention : les listes "developer" sont pour les développeurs DE PostgreSQL uniquement !

2. Forum de la communauté francophone :

http://forums.postgresql.fr/

3. Remarque : comment poser vos questions?

Si vous posez une question parce que vous avez un problème, vous voulez certainement qu'il soit résolu le plus vite possible. Alors pensez à ceux qui vont tenter de vous aider, et faites-leur gagner du temps en donnant les informations nécessaires. Soyez le plus clair possible.

Pensez à préciser au minimum :

  • La version de PostgreSQL utilisée,
  • Le système d'exploitation.,
  • ce que vous avez fait,
  • ce que vous vouliez faire,
  • le message d'erreur (ou son absence),
  • le résultat obtenu.

Si vous n'arrivez pas à vous connecter, précisez si le client est sur la même machine que le serveur. Recopiez les messages d'erreurs, consultez la log... enfin donnez le maximum d'informations pertinentes, et si on vous pose des questions, répondez-y le plus précisément possible.
Evitez également de dire qu'il y a un bug si vous n'en êtes pas absolement certain(e), et postez sur la mailing-list ou le forum approprié (par exemple, la mailing-list pour les novices n'est pas un endroit indigne, et des hackers y répondent régulièrement et avec bienveillance)

par florence le mardi 6 décembre 2011 à 23h08

dimanche 4 décembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 27 novembre 2011

FOSDEM 2012 - PostgreSQL Devroom: l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/

Offres d'emplois autour de PostgreSQL en novembre

PostgreSQL Local

  • L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
  • FOSDEM 2012 - PostgreSQL Devroom: l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/
  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • Fix citext upgrade script to update derived copies of pg_type.typcollation. If the existing citext type has not merely been created, but used in any tables, then the upgrade script wasn't doing enough. We have to update attcollation for each citext table column, and indcollation for each citext index column, as well. Per report from Rudolf van der Leeden. http://git.postgresql.org/pg/commitdiff/9b97b7f8356c63ea0b6704718d75ea01ec3035bf
  • More code review for rangetypes patch. Fix up some infelicitous coding in DefineRange, and add some missing error checks. Rearrange operator strategy number assignments for GiST anyrange opclass so that they don't make such a mess of opr_sanity's table of operator names associated with different strategy numbers. Assign hopefully-temporary selectivity estimators to range operators that didn't have one --- poor as the estimates are, they're still a lot better than the default 0.5 estimate, and they'll shut up the opr_sanity test that wants to see selectivity estimators on all built-in operators. http://git.postgresql.org/pg/commitdiff/a4ffcc8e115ed637f69ecb0295d78cc97f08a483
  • Still more review for range-types patch. Per discussion, relax the range input/construction rules so that the only hard error is lower bound > upper bound. Cases where the lower bound is <= upper bound, but the range nonetheless normalizes to empty, are now permitted. Fix core dump in range_adjacent when bounds are infinite. Marginal cleanup of regression test cases, some more code commenting. http://git.postgresql.org/pg/commitdiff/766948beddef66dd89563f465919eca6e131861c
  • Improve implementation of range-contains-element tests. Implement these tests directly instead of constructing a singleton range and then applying range-contains. This saves a range serialize/deserialize cycle as well as a couple of redundant bound-comparison steps, and adds very little code on net. Remove elem_contained_by_range from the GiST opclass: it doesn't belong there because there is no way to use it in an index clause (where the indexed column would have to be on the left). Its commutator is in the opclass, and that's what counts. http://git.postgresql.org/pg/commitdiff/cddc819e45010492da00164d225a749661f43aef
  • Remove zero- and one-argument range constructor functions. Per discussion, the zero-argument forms aren't really worth the catalog space (just write 'empty' instead). The one-argument forms have some use, but they also have a serious problem with looking too much like functional cast notation; to the point where in many real use-cases, the parser would misinterpret what was wanted. Committing this as a separate patch, with the thought that we might want to revert part or all of it if we can think of some way around the cast ambiguity. http://git.postgresql.org/pg/commitdiff/df73584431e7edb1dd76578777bd0fcc17b916a1
  • Remove user-selectable ANALYZE option for range types. It's not clear that a per-datatype typanalyze function would be any more useful than a generic typanalyze for ranges. What *is* clear is that letting unprivileged users select typanalyze functions is a crash risk or worse. So remove the option from CREATE TYPE AS RANGE, and instead put in a generic typanalyze function for ranges. The generic function does nothing as yet, but hopefully we'll improve that before 9.2 release. http://git.postgresql.org/pg/commitdiff/74c1723fc8dca2d70576ef2f0a66f4a7c99c173a
  • Creator of a range type must have permission to call support functions. Since range types can be created by non-superusers, we need to consider their permissions. Ideally we'd check this when the type is used, not when it's created, but that seems like much more trouble than it's worth. The existing restriction that the support functions be immutable already prevents most cases where an unauthorized call to a function might be thought a security issue, and the fact that the user has no access to the results of the system's calls to subtype_diff closes off the other plausible reason for concern. So this check is basically pro-forma, but let's make it anyway. http://git.postgresql.org/pg/commitdiff/a912a2784be5d144aab89e447dfe8ca74b6ad079
  • Adjust range_adjacent to support different canonicalization rules. The original coding would not work for discrete ranges in which the canonicalization rule is to produce symmetric boundaries (either [] or () style), as noted by Jeff Davis. Florian Pflug pointed out that we could fix that by invoking the canonicalization function to see if the range "between" the two given ranges normalizes to empty. This implementation of Florian's idea is a tad slower than the original code, but only in the case where there actually is a canonicalization function --- if not, it's essentially the same logic as before. http://git.postgresql.org/pg/commitdiff/b7056b832444696c931d59af057b0a345f5ae178
  • Some more editing of the range-types documentation. Be more thorough about specifying the expectations for canonical and subtype_diff functions, and move that info to the same place. http://git.postgresql.org/pg/commitdiff/604d4c4c95c44090af25083ce6624fea3ebb4553
  • Fix unsupported options in CREATE TABLE ... AS EXECUTE. The WITH [NO] DATA option was not supported, nor the ability to specify replacement column names; the former limitation wasn't even documented, as per recent complaint from Naoya Anzai. Fix by moving the responsibility for supporting these options into the executor. It actually takes less code this way ... catversion bump due to change in representation of IntoClause, which might affect stored rules. http://git.postgresql.org/pg/commitdiff/9ed439a9c07b69c2617cc98596611fdbdc22472c
  • Fix erroneous replay of GIN_UPDATE_META_PAGE WAL records. A simple thinko in ginRedoUpdateMetapage, namely failing to increment a loop counter, led to inserting records into the last pending-list page in the wrong order (the opposite of that intended). So far as I can tell, this would not upset the code that eventually flushes pending items into the main part of the GIN index. But it did break the code that searched the pending list for matches, resulting in transient failure to find matching entries during index lookups, as illustrated in bug #6307 from Maksym Boguk. Back-patch to 8.4 where the incorrect code was introduced. http://git.postgresql.org/pg/commitdiff/877b67c38b946dcbf70fe11736bdde841e4c826b
  • Fix overly-aggressive and inconsistent quoting in OS X start script. Sidar Lopez, per bug #6310, with some additional improvements by me. Back-patch to 9.0, where the issue was introduced. http://git.postgresql.org/pg/commitdiff/6c8768c3861d6690656b74676c44ffa63c0e4ef7
  • Make GiST index searches smarter about queries against empty ranges. In the cases where the result of the called proc is negated, we should explicitly test both inputs for empty, to ensure we'll never return "true" for an unsatisfiable query. In other cases we can rely on the called proc to say the right thing. http://git.postgresql.org/pg/commitdiff/5966bcecf6167f2921e614e66499fa4d2c195c64
  • Use the proper macro to convert a bool to a Datum. The original coding was var->value = (Datum) state; which is bogus, and then in commit 2f0f7b4bce13e68394543728801ef011fd82fac6 it was "corrected" to var->value = PointerGetDatum(state); which is a faithful translation but still wrong. This seems purely cosmetic, though, so no need for a back-patch. Pavel Stehule http://git.postgresql.org/pg/commitdiff/8722a1a06aedbbbeb4f848a7b9ee62d6ae8649c6
  • Improve GiST range-contained-by searches by adding a flag for empty ranges. In the original implementation, a range-contained-by search had to scan the entire index because an empty range could be lurking anywhere. Improve that by adding a flag to upper GiST entries that says whether the represented subtree contains any empty ranges. Also, make a simple mod to the penalty function to discourage empty ranges from getting pushed into subtrees without any. This needs more work, and the picksplit function should be taught about it too, but that code can be improved without causing an on-disk compatibility break; so we'll leave it for another day. Since we're breaking on-disk compatibility of range values anyway, I took the opportunity to reorganize the range flags bits; the unused RANGE_xB_NULL bits are now adjacent, which might open the door for using them in some other way later. In passing, remove the GiST range opclass entry for <>, which doesn't seem like it can really be indexed usefully. Alexander Korotkov, with some editorializing by Tom Lane. http://git.postgresql.org/pg/commitdiff/c66e4f138b04d749a713ad075e16f3d60975f5ad
  • Use IEEE infinity, not 1e10, for null-and-not-null case in gistpenalty(). Use of a randomly chosen large value was never exactly graceful, and now that there are penalty functions that are intentionally using infinity, it doesn't seem like a good idea for null-vs-not-null to be using something less. http://git.postgresql.org/pg/commitdiff/9f4563f743eab0682f908d51fa3a9c630b31322d
  • Ensure that whole-row junk Vars are always of composite type. The EvalPlanQual machinery assumes that whole-row Vars generated for the outputs of non-table RTEs will be of composite types. However, for the case where the RTE is a function call returning a scalar type, we were doing the wrong thing, as a result of sharing code with a parser case where the function's scalar output is wanted. (Or at least, that's what that case has done historically; it does seem a bit inconsistent.) To fix, extend makeWholeRowVar's API so that it can support both use-cases. This fixes Belinda Cussen's report of crashes during concurrent execution of UPDATEs involving joins to the result of UNNEST() --- in READ COMMITTED mode, we'd run the EvalPlanQual machinery after a conflicting row update commits, and it was expecting to get a HeapTuple not a scalar datum from the "wholerowN" variable referencing the function RTE. Back-patch to 9.0 where the current EvalPlanQual implementation appeared. In 9.1 and up, this patch also fixes failure to attach the correct collation to the Var generated for a scalar-result case. An example: regression=# select upper(x.*) from textcat('ab', 'cd') x; ERROR: could not determine which collation to use for upper() function http://git.postgresql.org/pg/commitdiff/dd3bab5fd74db009c946278bb314c8458a2fef11

Simon Riggs a poussé :

Peter Eisentraut a poussé :

Robert Haas a poussé :

  • Check for INSERT privileges in SELECT INTO / CREATE TABLE AS. In the normal course of events, this matters only if ALTER DEFAULT PRIVILEGES has been used to revoke default INSERT permission. Whether or not the new behavior is more or less likely to be what the user wants when dealing only with the built-in privilege facilities is arguable, but it's clearly better when using a loadable module such as sepgsql that may use the hook in ExecCheckRTPerms to enforce additional permissions checks. KaiGai Kohei, reviewed by Laurenz Albe http://git.postgresql.org/pg/commitdiff/f1b4aa2a84732255bd8a34fc9c7994a04409b77a
  • Move "hot" members of PGPROC into a separate PGXACT array. This speeds up snapshot-taking and reduces ProcArrayLock contention. Also, the PGPROC (and PGXACT) structures used by two-phase commit are now allocated as part of the main array, rather than in a separate array, and we keep ProcArray sorted in pointer order. These changes are intended to minimize the number of cache lines that must be pulled in to take a snapshot, and testing shows a substantial increase in performance on both read and write workloads at high concurrencies. Pavan Deolasee, Heikki Linnakangas, Robert Haas http://git.postgresql.org/pg/commitdiff/ed0b409d22346b1b027a4c2099ca66984d94b6dd

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

Alvaro Herrera a poussé :

Andrew Dunstan a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Mark Kirkwood sent in two revisions of a patch to allow renaming a database which has backends connected to it.
  • Peter Geoghegan sent in four more revisions of a patch to inline comparators as a performance optimization.
  • Alexander Korotkov sent in a WIP patch to allow index support for regex operators.
  • Jan Urbanski sent in another revision of the patch to add cursor support to PL/PythonU.
  • Pavel Stehule sent in a WIP patch to enable better support for debugging overloaded functions in PL/pgsql.
  • Lars Kanis sent in two revisions of a patch to fix some infelicities in certain versions of MSVC.
  • Pavel Stehule sent in a PoC patch to use errcontext for custom exceptions in PL/pgsql.
  • Andrew Dunstan sent in another revision of a patch to add a \setenv command to psql.
  • Dimitri Fontaine sent in another revision of the patch to add command triggers.
  • Peter Eisentraut sent in a patch to fix error reports in vpath builds.
  • Pavel Stehule sent in another revision of the patch to add CHECK FUNCTION and CHECK TRIGGER functionality.
  • Andres Freund and Pavan Deolasee traded patches to avoid unneeded computation of snapshots.
  • Peter Eisentraut sent in a patch to allow psql to report the line number on which an error occurred when reading from stdin.
  • Ants Aasma sent in a patch to implement timing of shared buffer fills and per relation stats collection of said timings. Buffer flushes are timed as well but aren't exposed per table because of difficulty of correctly attributing them.

par N Bougain le dimanche 4 décembre 2011 à 17h57

Nouvelles hebdomadaires de PostgreSQL - 20 novembre 2011

FOSDEM 2012 - PostgreSQL Devroom: l'appel à conférenciers est ouvert jusqu'au 20 décembre 2011 : https://www.postgresql.eu/events/callforpapers/fosdem2012/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en novembre

PostgreSQL Local

  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
  • La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Bruce Momjian a poussé :

Tom Lane a poussé :

  • Fix copyright notices, other minor editing in new range-types code. No functional changes in this commit (except I could not resist the temptation to re-word a couple of error messages). This is just manual cleanup after pgindent to make the code look reasonably like other PG code, in preparation for more detailed code review to come. http://git.postgresql.org/pg/commitdiff/f1585362856d4da17113ba2e4ba46cf83cba0cf2
  • Return FALSE instead of throwing error for comparisons with empty ranges. Change range_before, range_after, range_adjacent to return false rather than throwing an error when one or both input ranges are empty. The original definition is unnecessarily difficult to use, and also can result in undesirable planner failures since the planner could try to compare an empty range to something else while deriving statistical estimates. (This was, in fact, the cause of repeatable regression test failures on buildfarm member jaguar, as well as intermittent failures elsewhere.) Also tweak rangetypes regression test to not drop all the objects it creates, so that the final state of the regression database contains some rangetype objects for pg_dump testing. http://git.postgresql.org/pg/commitdiff/851c83fc81917c61b063c875fc1bca489dfcc482
  • Return NULL instead of throwing error when desired bound is not available. Change range_lower and range_upper to return NULL rather than throwing an error when the input range is empty or the relevant bound is infinite. Per discussion, throwing an error seems likely to be unduly hard to work with. Also, this is more consistent with the behavior of the constructors, which treat NULL as meaning an infinite bound. http://git.postgresql.org/pg/commitdiff/4f9e33063cea270166fba12d89fe49876f814398
  • Update oidjoins regression test to match git HEAD. This is mostly to add some sanity checking for the pg_range catalog. http://git.postgresql.org/pg/commitdiff/4165d5b6d7d2e399edbc6d027039358794aa8f04
  • Fix alignment and toasting bugs in range types. A range type whose element type has 'd' alignment must have 'd' alignment itself, else there is no guarantee that the element value can be used in-place. (Because range_deserialize uses att_align_pointer which forcibly aligns the given pointer, violations of this rule did not lead to SIGBUS but rather to garbage data being extracted, as in one of the added regression test cases.) Also, you can't put a toast pointer inside a range datum, since the referenced value could disappear with the range datum still present. For consistency with the handling of arrays and records, I also forced decompression of in-line-compressed bound values. It would work to store them as-is, but our policy is to avoid situations that might result in double compression. Add assorted regression tests for this, and bump catversion because of fixes to built-in pg_type entries. Also some marginal cleanup of inconsistent/unnecessary error checks. http://git.postgresql.org/pg/commitdiff/ad50934eaadb626de682defe0ad270bbf31e92a2
  • Restructure function-internal caching in the range type code. Move the responsibility for caching specialized information about range types into the type cache, so that the catalog lookups only have to occur once per session. Rearrange APIs a bit so that fn_extra caching is actually effective in the GiST support code. (Use of OidFunctionCallN is bad enough for performance in itself, but it also prevents the function from exploiting fn_extra caching.) The range I/O functions are still not very bright about caching repeated lookups, but that seems like material for a separate patch. Also, avoid unnecessary use of memcpy to fetch/store the range type OID and flags, and don't use the full range_deserialize machinery when all we need to see is the flags value. Also fix API error in range_gist_penalty --- it was failing to set *penalty for any case involving an empty range. http://git.postgresql.org/pg/commitdiff/37ee4b75db8f979da6d67ba153d068b012394b46
  • Improve caching in range type I/O functions. Cache the the element type's I/O info across calls, not only the range type's info. In passing, also clean up hash_range a bit more. http://git.postgresql.org/pg/commitdiff/04da3232907680caad3445928c97a246c626a14a
  • Code review for range-types catalog entries. Fix assorted infelicities, such as dependency on OIDs that aren't hardwired, as well as outright misdeclaration of daterange_canonical(), which resulted in crashes if you invoked it directly. Add some more regression tests to try to catch similar mistakes in future. http://git.postgresql.org/pg/commitdiff/4509033a00df5f49c42a21772d8d617efe83e549
  • Fix range_cmp_bounds for the case of equal-valued exclusive bounds. Also improve its comments and related regression tests. Jeff Davis, with some further adjustments by Tom Lane. http://git.postgresql.org/pg/commitdiff/bf4f96b5e264f1c0f5d8694f11c6f9f5b3132b3b
  • Extend the unknowns-are-same-as-known-inputs type resolution heuristic. For a very long time, one of the parser's heuristics for resolving ambiguous operator calls has been to assume that unknown-type literals are of the same type as the other input (if it's known). However, this was only used in the first step of quickly checking for an exact-types match, and thus did not help in resolving matches that require coercion, such as matches to polymorphic operators. As we add more polymorphic operators, this becomes more of a problem. This patch adds another use of the same heuristic as a last-ditch check before failing to resolve an ambiguous operator or function call. In particular this will let us define the range inclusion operator in a less limited way (to come in a follow-on patch). http://git.postgresql.org/pg/commitdiff/1a8b9fb5499d8646661a57edd3c88c3107622ff8
  • Declare range inclusion operators as taking anyelement not anynonarray. Use of anynonarray was a crude hack to get around ambiguity versus the array inclusion operators of the same names. My previous patch to extend the parser's type resolution heuristics makes that unnecessary, so use the more general declaration instead. This eliminates a wart that these operators couldn't be used with ranges over arrays, which are otherwise supported just fine. Also, mark range_before and range_after as commutator operators, per discussion with Jeff Davis. http://git.postgresql.org/pg/commitdiff/709aca59608395eef9ceb7dcb79fd9d03a0709ef
  • Do missed autoheader run for previous commit. http://git.postgresql.org/pg/commitdiff/f6438f66226e37851e11a93edebae0198a875100
  • Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests. http://git.postgresql.org/pg/commitdiff/a1a233af66ed14d225ac2d5e7948a5cc8ed2cde6
  • Avoid floating-point underflow while tracking buffer allocation rate. When the system is idle for awhile after activity, the "smoothed_alloc" state variable in BgBufferSync converges slowly to zero. With standard IEEE float arithmetic this results in several iterations with denormalized values, which causes kernel traps and annoying log messages on some poorly-designed platforms. There's no real need to track such small values of smoothed_alloc, so we can prevent the kernel traps by forcing it to zero as soon as it's too small to be interesting for our purposes. This issue is purely cosmetic, since the iterations don't happen fast enough for the kernel traps to pose any meaningful performance problem, but still it seems worth shutting up the log messages. The kernel log messages were previously reported by a number of people, but kudos to Greg Matthews for tracking down exactly where they were coming from. http://git.postgresql.org/pg/commitdiff/40d35036bb160d5724305454d41c68ab1637ee6f
  • Further code review for range types patch. Fix some bugs in coercion logic and pg_dump; more comment cleanup; minor cosmetic improvements. http://git.postgresql.org/pg/commitdiff/b985d48779146b7ba969b0963614ad7683589bc8

Robert Haas a poussé :

  • Don't elide blank lines when accumulating psql command history. This can change the meaning of queries, if the blank line happens to occur in the middle of a quoted literal, as per complaint from Tomas Vondra. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/ff4fd4bf53c5512427f8ecea08d6ca7777efa2c5
  • Restructure get_object_address() so it's safe against concurrent DDL. This gives a much better error message when the object of interest is concurrently dropped and avoids needlessly failing when the object of interest is concurrently dropped and recreated. It also improves the behavior of two concurrent DROP IF EXISTS operations targeted at the same object; as before, one will drop the object, but now the other will emit the usual NOTICE indicating that the object does not exist, instead of rolling back. As a fringe benefit, it's also slightly less code. http://git.postgresql.org/pg/commitdiff/b3ad5d02c9cd8a4c884cd78480f221afe8ce5590
  • Remove ancient downcasing code from procedural language operations. A very long time ago, language names were specified as literals rather than identifiers, so this code was added to do case-folding. But that style has ben deprecated for many years so this isn't needed any more. Language names will still be downcased when specified as unquoted identifiers, but quoted identifiers or the old style using string literals will be left as-is. http://git.postgresql.org/pg/commitdiff/67dc4eed42186ba6a2456578899bfd38d003201a
  • Further consolidation of DROP statement handling. This gets rid of an impressive amount of duplicative code, with only minimal behavior changes. DROP FOREIGN DATA WRAPPER now requires object ownership rather than superuser privileges, matching the documentation we already have. We also eliminate the historical warning about dropping a built-in function as unuseful. All operations are now performed in the same order for all object types handled by dropcmds.c. KaiGai Kohei, with minor revisions by me http://git.postgresql.org/pg/commitdiff/fc6d1006bda783cc002c61a5f072905849dbde4b

Michael Meskes a poussé :

Alvaro Herrera a poussé :

Simon Riggs a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Yeb Havinga sent in two more revisions of the patch to add named parameters to cursor calls.
  • Greg Smith sent in another revision of the patch to restructure how core extensions are placed in the source tree.
  • Bruce Momjian sent in a patch to fix an infelicity between pg_dump and malloc.
  • Jaime Casanova sent in another revision of the patch to measure relation free space.
  • Shigeru HANADA sent in another revision of the patch to remove useless columns from the system catalog table entries associated with foreign tables.
  • Simon Riggs sent in a PoC patch to add group commit.
  • Andrew Dunstan sent in another revision of the patch to create distinctions in pg_dump/pg_restore among pre-data, data, and post-data as distinct entities.
  • Shigeru HANADA sent in another revision of the patch to make it possible for the server to push JOINs to the foreign server, along with infrastructure for same.
  • Greg Smith sent in another revision of the patch to allow displaying accumulated autovacuum cost.
  • Julien Tachoires sent in another revision of the patch to allow moving a table, its TOAST table, or both to a new tablespace.
  • Shigeru HANADA sent in a new flock of patches to enable a pgsql_fdw.
  • Scott Mead sent in two more revisions of a patch to introspect states that are "<IDLE> in transaction."
  • Laurenz Albe sent in two more revisions of a patch to allow disabling SSL compression.
  • KaiGai Kohei sent in another flock of patches refactoring DDL, one part of which (DROP) Robert Haas updated and committed.
  • KaiGai Kohei sent in another revision of the patch to allow object creation hooks, which sepgsql will eventually use.
  • Simon Riggs sent in a patch to optimize XLogInsert().
  • Robert Haas and Pavan Deolasee traded patches to implement a new refactor of the locking system called FlexLocks.
  • Peter Eisentraut sent in a patch for type privileges.
  • Josh Kupershmidt sent in a patch to fix an infelicity in psql's \ir feature.
  • Greg Smith sent in a revived version of an old patch to allow including a whole directory in postgresql.conf.
  • Greg Smith sent in a patch to add an "include if exists" directive in postgresql.conf.
  • Edward Muller sent in another revision of the patch to allow users to kill their own queries.
  • Zoltan Boszormenyi sent in a patch to allow FETCH read-ahead in ECPG.
  • Tom Lane sent in a patch to avoid losing column names in some cases.
  • Etsuro Fujita sent in another revision of the patch that makes it possible to collect statistics on FDW data, including an implementation for the CSV FDW.
  • Andres Freund sent in two revisions of a patch to collapse a long chain of "ifs" in eval_const_expressions_mutator into a "switch" statement.
  • KaiGai Kohei sent in another revision of the patch to add a permission check on SELECT INTO.
  • Andres Freund sent in a patch to allow the combination of (plan off, rewrite off) in EXPLAIN for benchmarking.

par N Bougain le dimanche 4 décembre 2011 à 17h54

samedi 3 décembre 2011

Samuel Roze

Symfony 2 et PostgreSQL: Mots réservés

Symfony 2 propose une abstraction des entities très intéressante grâce à Doctrine. Je poste ce petit article car j’ai eu une erreur tout simple:

 $ php app/console doctrine:schema:update --force
Updating database schema...
 
[PDOException] SQLSTATE[42601]: Syntax error: 7 ERREUR:  erreur de syntaxe sur ou près de « User » 
LINE 1: CREATE TABLE User (id INT NOT NULL, username VARCHAR(255) NO...              
                       ^          

En fait, j’ai créé un bundle nommé User, et doctrine souhaite donc créer la table User. Le problème, c’est que user est un mot clé réservé dans PostgreSQL. Par conséquent, il faut donc forcer Doctrine à escaper le nom de la table. Pour se faire, il suffit d’ajouter une annotation Table en préfixant et suffixant le nom de la table par `.

Voici par exemple ma classe User avant la correction:

/**
 * @ORM\Entity
 */
class User extends BaseUser
{
    // ...
}

Il suffit donc de d’ajouter l’annotation @ORM\Table en spécifiant le nom de la table entouré de `. Le nouveau code est:

/**
 * @ORM\Entity
 * @ORM\Table(name="`User`")
 */
class User extends BaseUser
{
    // ...
}

Ainsi, Doctrine va générer ses requêtes en ajoutant des caractères d’échappement sur le nom de la table. Ainsi, vous n’aurez plus d’erreur! :)

par Samuel ROZE le samedi 3 décembre 2011 à 18h12

jeudi 17 novembre 2011

Dimitri Fontaine (2nd Quadrant)

Oracle, SQL Server, PostgreSQL

Changer de système de gestion de bases de données n’est que rarement une tâche simple.  L’une des premières étapes de la validation de la migration consiste à valider son intérêt en termes de coûts et de bénéfices, parfois aussi appelé « retour sur investissement ».  J’ai lu récemment un article qui détaille des points techniques pour lesquels une migration vers PostgreSQL peut s’avérer coûteuse, Migration Oracle PostgreSQL : les 13 grandes lacunes qui peuvent s’avérer cauchemardesque.

Cet article est très intéressant et le point de vue exprimé me semble honnête et sincère, je regrette seulement que tout ne soit pas exact ou à jour dans les détails concernant PostgreSQL. Globalement, il est vrai que les concurrents propriétaires de notre solution Open Source favorite disposent encore de fonctionnalités avancées que nous ne retrouvons pas dans PostgreSQL, et cela peut s’avérer déstabilisant ou bien peut nuire à votre capacité à migrer vers PostgresQL.

Il faut se rendre compte que PostgreSQL n’étant pas édité par une entreprise unique, les fonctionnalités de chaque nouvelle version sont celles que les développeurs ont choisi d’implémenter. Pas de département Marketing pour arbitrer les éléments à ajouter dans cette fameuse liste qui aide les commerciaux à mieux faire leur travail. L’avantage de cette organisation est qu’elle permet à tout utilisateur de participer à établir les priorités du développement du projet, en contribuant les fonctionnalités manquantes. Cela peut se faire directement lorsque l’on dispose des compétences nécessaires en interne, ou bien en sponsorisant une entreprise spécialisée, telle 2ndQuadrant.

Pour être juste avec l’auteur de l’article précédent, rappelons tout de même qu’il détaille un point de vue technique d’administrateur de bases de données qui s’attache à résoudre les problèmes réels qui font son quotidien, la remarque sur l’influence du Marketing n’est pas une remarque sur l’article référencé ci-dessus.

Répondre aux 13 points cités serait trop long et trop technique pour le faire ici. Prenons tout de même le temps d’en relever quelques uns, qui illustrent l’attitude du projet PostgreSQL.  La gestion des espaces de stockage, par exemple, est laissée aux programmes spécialisés (tels LVM), car les développeurs de PostgreSQL utilisent le système de fichiers et de blocs sous-jacents et refusent d’en dupliquer les fonctionnalités.

Quant à la gestion des transactions, rappelons qu’avec la sortie de PostgreSQL 9.1 plus tôt cette année, nous offrons la seule implémentation du niveau sérialisable qui ne repose pas sur des verrous forts et qui soit démontrée correcte. Ce qui fait défaut à PostgreSQL est la notion de procédure permettant de contrôler des transactions autonomes. Il est possible de contourner cette absence en utilisant les outils dblink ou plproxy, et je connais plusieurs société d’expertise qui seront heureuses de vous expliquer comment faire cela.

La partitionement dans PostgreSQL est un sujet qui mériterait un billet à lui tout seul. C’est un problème que nous voulons résoudre chez 2ndQuadrant, et nous avons plusieurs pistes afin d’arriver à une bonne solution. Sponsoriser nos travaux sur le sujet est un des meilleurs moyens à votre disposition afin de faciliter votre migration vers PostgreSQL dès la sortie de sa prochaine version majeure. Ce même raisonnement s’applique parfaitement aux requêtes parallèles, autre sujet important sur lequel nous saurons vous aider.

Il existe des moyens d’influencer l’optimisation de requêtes que réalise PostgreSQL, mais pas avec les fameux indices de requêtes. Utiliser ceux-ci pose de grands problèmes de compatibilité et demande de revoir l’ensemble des requêtes qui les utilisent pour toute migration à une version majeure plus récente de votre SBGD propriétaire, il me semble. Le compromis n’est pas si facile à faire.

Les index couvrants ont été développés (par Robert Haas, qui travaille pour EnterpriseDB) et seront disponibles dans PostgreSQL 9.2, sans avoir à déclarer quoi que ce soit. Si les seules colonnes dont vous avez besoin sont indexées, alors PostgreSQL saura seul en tirer parti. Le profilage de requête est grandement amélioré pour la prochaine version de PostgreSQL, suite à des travaux réalisés par 2ndQuadrant.

Enfin, PostgreSQL dispose en versions 9.0 et 9.1 d’une solution de réplication intégrée. Cela est le résultat des 7 dernières années de travaux de Simon Riggs (2ndQuadrant) concernant la gestion des journaux de transaction. En version 9.1 PostgreSQL propose une solution de réplication synchrone contrôlable pour chaque transaction. Vous pouvez faire cohabiter une réplication synchrone et une réplication asynchrone au sein de la même installation de bases de données afin de bénéficier simultanément des avantages de sécurité et durabilité des données sans nuire aux performances des transactions moins importantes. Une fois de plus, cela est une première mondiale, nul autre système de gestion de bases de données ne dispose d’une telle solution.

En conclusion, l’article que j’ai référencé au début de ce billet est une bonne lecture même s’il n’est pas suffisamment à jour. Certaines utilisations des SGBD propriétaires peuvent s’avérer difficiles à reproduire sous PostgreSQL et il est indispensable de savoir évaluer cela dès le début de l’analyse de faisabilité et de coûts. Dans bien des cas cependant, participer à la mise au point de la fonctionnalité manquante en en finançant le développement sera la meilleure stratégie possible. Le retour sur investissement ne sera qu’assez peu modifié : étant donné les prix des licences propriétaires, on a vu (en conférence PostgreSQL Europe à Amsterdam) des projets inclure un développement spécifique et voir son retour sur investissement passer de 2 mois à… 8 mois, ce qui reste inférieur à 1 an!

Alors, qu’attendez-vous pour évaluer les bénéfices que vous aurez à migrer vers PostgreSQL ?

par Dimitri Fontaine le jeudi 17 novembre 2011 à 17h30

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 13 novembre 2011

La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en novembre

PostgreSQL Local

  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • On second thought, we'd better just drop these tests altogether. Further experimentation reveals that my previous change didn't fix the issue entirely: these tests would still fail at the spring-forward DST transition. There doesn't seem to be any great value in testing this specific issue for both timestamp and timestamptz, so just lose the latter tests. http://git.postgresql.org/pg/commitdiff/f62be400c0e2369d68b4327ced721e47250dc40c
  • Fix assorted bugs in contrib/unaccent's configuration file parsing. Make it use t_isspace() to identify whitespace, rather than relying on sscanf which is known to get it wrong on some platform/locale combinations. Get rid of fixed-size buffers. Make it actually continue to parse the file after ignoring a line with untranslatable characters, as was obviously intended. The first of these issues is per gripe from J Smith, though not exactly either of his proposed patches. http://git.postgresql.org/pg/commitdiff/ced3a93ccbbd0a3866f2324662f7a1fa4c31909a
  • Wrap appendrel member outputs in PlaceHolderVars in additional cases. Add PlaceHolderVar wrappers as needed to make UNION ALL sub-select output expressions appear non-constant and distinct from each other. This makes the world safe for add_child_rel_equivalences to do what it does. Before, it was possible for that function to add identical expressions to different EquivalenceClasses, which logically should imply merging such ECs, which would be wrong; or to improperly add a constant to an EquivalenceClass, drastically changing its behavior. Per report from Teodor Sigaev. The only currently known consequence of this bug is "MergeAppend child's targetlist doesn't match MergeAppend" planner failures in 9.1 and later. I am suspicious that there may be other failure modes that could affect older release branches; but in the absence of any hard evidence, I'll refrain from back-patching further than 9.1. http://git.postgresql.org/pg/commitdiff/57664ed25e5dea117158a2e663c29e60b3546e1c
  • Fix random discrepancies between parallel_schedule and serial_schedule. In particular, my previous patch expected the create_index test to run before the inherit test; but this was only true in the serial schedule. Rearrange this portion of the schedules to be more consistent. Per buildfarm results. http://git.postgresql.org/pg/commitdiff/6d295b64945cb6ff9b64f55d1e51b5e2a1bb6f84
  • Tweak new regression test case for more portability. Ensure that same index gets selected on 32-bit and 64-bit machines. Per buildfarm results. http://git.postgresql.org/pg/commitdiff/2c30f96103c320d4e3c8cab2807d88476f584278
  • Avoid platform-dependent infinite loop in pg_dump. If malloc(0) returns NULL, the binary search in findSecLabels() will probably go into an infinite loop when there are no security labels, because NULL-1 is greater than NULL after wraparound. (We've seen this pathology before ... I wonder whether there's a way to detect the class of bugs automatically?) Diagnosis and patch by Steve Singer, cosmetic adjustments by me http://git.postgresql.org/pg/commitdiff/cf22e851b6ae8737f3e767dffcadf1722fbb36a7
  • Throw nice error if server is too old to support psql's \ef or \sf command. Previously, you'd get "function pg_catalog.pg_get_functiondef(integer) does not exist", which is at best rather unprofessional-looking. Back-patch to 8.4 where \ef was introduced. Josh Kupershmidt http://git.postgresql.org/pg/commitdiff/6f3dc00e24aa2a8e7e2c5e5095b6223712b8204c
  • In plpgsql, allow foreign tables to define row types. This seems to have been just an oversight in previous foreign-table work. A quick grep didn't turn up any other places where RELKIND_FOREIGN_TABLE was obviously omitted. One change noted by Alexander Soudakov, the other by me. Back-patch to 9.1. http://git.postgresql.org/pg/commitdiff/02d88efea1f719e59ce684c2e14bad23d55fdd15

Heikki Linnakangas a poussé :

Robert Haas a poussé :

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Simon Riggs a poussé :

  • Wakeup WALWriter as needed for asynchronous commit performance. Previously we waited for wal_writer_delay before flushing WAL. Now we also wake WALWriter as soon as a WAL buffer page has filled. Significant effect observed on performance of asynchronous commits by Robert Haas, attributed to the ability to set hint bits on tuples earlier and so reducing contention caused by clog lookups. http://git.postgresql.org/pg/commitdiff/4de82f7d7c50a81ec8e70e2cb0ab413ab9134c0b

Michael Meskes a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Peter Eisentraut sent in the first of several patches to quiet warnings generated when using -Wcast-qual.
  • Thomas Munro and Kevin Grittner traded patches which const-ify functions, per TODO item.
  • KaiGai Kohei sent in two more revisions of the patch to add object access hooks with argument support.
  • Alexander Korotkov sent in two revisions of a patch to add GiST indexing for range types.
  • Heikki Linnakangas sent in another revision of the patch to store hot members of PGPROC out of band.
  • Simon Riggs sent in a patch to use a latch in WalWriter.
  • Robert Haas and Simon Riggs traded patches intended to reduce contention on ProcArrayLock.
  • Jaime Casanova sent in another revision of the patch to allow seeing relation free space.
  • Laurenz Albe sent in a patch to allow disabling SSL compression.
  • Dimitri Fontaine sent in a PoC patch to create command triggers.
  • Alexander Korotkov sent in another revision of the patch to collect frequency statistics for arrays.
  • Robert Haas sent in a patch to improve error messages emitted by get_object_address().
  • Dimitri Fontaine sent in two revisions of a patch to add Node support in outfuncs.c and readfuncs.c
  • Tomas Vondra sent in a PoC patch to allow triggers on backend startup.
  • Nikhil Sontakke and Robert Haas traded patches to fix a situation where concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers.
  • José Arthur Benetasso Villanova and Jan Kundrát traded patches to add context in error messages where check constraints are violated.
  • Kyotaro HORIGUCHI sent in a patch to allow plugging in different memory allocators into libpq.
  • Andrew Dunstan sent in a patch to add finer control to pg_dump/pg_restore by making the dividing lines among pre-data, data and post-data sections explicit.
  • Robert Haas sent in two revisions of a patch to reduce the number of snapshots taken per query by half.
  • Simon Riggs sent in a patch to allow fast failover.
  • Jan Urbanski sent in another revision of the patches to refactor PL/Python.
  • Greg Smith sent in a patch which adds query normalization of pg_stat_statements, based on transforming the query tree into a series of integers and using them to match against previous queries.

par N Bougain le jeudi 17 novembre 2011 à 00h58

samedi 12 novembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 6 novembre 2011

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en novembre

PostgreSQL Local

  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

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

  • Stop btree indexscans upon reaching nulls in either direction. The existing scan-direction-sensitive tests were overly complex, and failed to stop the scan in cases where it's perfectly legitimate to do so. Per bug #6278 from Maksym Boguk. Back-patch to 8.3, which is as far back as the patch applies easily. Doesn't seem worth sweating over a relatively minor performance issue in 8.2 at this late date. (But note that this was a performance regression from 8.1 and before, so 8.2 is being left as an outlier.) http://git.postgresql.org/pg/commitdiff/6980f817e83c242c29c84a44f1e1f09e566439b7
  • Fix race condition with toast table access from a stale syscache entry. If a tuple in a syscache contains an out-of-line toasted field, and we try to fetch that field shortly after some other transaction has committed an update or deletion of the tuple, there is a race condition: vacuum could come along and remove the toast tuples before we can fetch them. This leads to transient failures like "missing chunk number 0 for toast value NNNNN in pg_toast_2619", as seen in recent reports from Andrew Hammond and Tim Uckun. The design idea of syscache is that access to stale syscache entries should be prevented by relation-level locks, but that fails for at least two cases where toasted fields are possible: ANALYZE updates pg_statistic rows without locking out sessions that might want to plan queries on the same table, and CREATE OR REPLACE FUNCTION updates pg_proc rows without any meaningful lock at all. The least risky fix seems to be an idea that Heikki suggested when we were dealing with a related problem back in August: forcibly detoast any out-of-line fields before putting a tuple into syscache in the first place. This avoids the problem because at the time we fetch the parent tuple from the catalog, we should be holding an MVCC snapshot that will prevent removal of the toast tuples, even if the parent tuple is outdated immediately after we fetch it. (Note: I'm not convinced that this statement holds true at every instant where we could be fetching a syscache entry at all, but it does appear to hold true at the times where we could fetch an entry that could have a toasted field. We will need to be a bit wary of adding toast tables to low-level catalogs that don't have them already.) An additional benefit is that subsequent uses of the syscache entry should be faster, since they won't have to detoast the field. Back-patch to all supported versions. The problem is significantly harder to reproduce in pre-9.0 releases, because of their willingness to flush every entry in a syscache whenever the underlying catalog is vacuumed (cf CatalogCacheFlushRelation); but there is still a window for trouble. http://git.postgresql.org/pg/commitdiff/08e261cbc94ce9a72c0660b2786eaadae9f6fb41
  • Preserve Var location information during flatten_join_alias_vars. This allows us to give correct syntax error pointers when complaining about ungrouped variables in a join query with aggregates or GROUP BY. It's pretty much irrelevant for the planner's use of the function, though perhaps it might aid debugging sometimes. http://git.postgresql.org/pg/commitdiff/391af9f7842ba8b8d2195aaf82879662434b97f3
  • Revert "Stop btree indexscans upon reaching nulls in either direction." This reverts commit 048fffed55ff1d6d346130e4a6b7be434e81e82c. As pointed out by Naoya Anzai, we need to do more work to make that idea handle end-of-index cases, and it is looking like too much risk for a back-patch. So bug #6278 is only going to be fixed in HEAD. http://git.postgresql.org/pg/commitdiff/5cd7b682427d0e912b3ddf7f4910d52089e0df71
  • Fix btree stop-at-nulls logic properly. As pointed out by Naoya Anzai, my previous try at this was a few bricks shy of a load, because I had forgotten that the initial-positioning logic might not try to skip over nulls at the end of the index the scan will start from. We ought to fix that, because it represents an unnecessary inefficiency, but first let's get the scan-stop logic back to a safe state. With this patch, we preserve the performance benefit requested in bug #6278 for the case of scanning forward into NULLs (in a NULLS LAST index), but the reverse case of scanning backward across NULLs when there's no suitable initial-positioning qual is still inefficient. http://git.postgresql.org/pg/commitdiff/882368e854b6f094f94aca292f390bbd9f44359b
  • Avoid scanning nulls at the beginning of a btree index scan. If we have an inequality key that constrains the other end of the index, it doesn't directly help us in doing the initial positioning ... but it does imply a NOT NULL constraint on the index column. If the index stores nulls at this end, we can use the implied NOT NULL condition for initial positioning, just as if it had been stated explicitly. This avoids wasting time when there are a lot of nulls in the column. This is the reverse of the examples given in bugs #6278 and #6283, which were about failing to stop early when we encounter nulls at the end of the indexscan. http://git.postgresql.org/pg/commitdiff/1a77f8b63d159b88ceb6245fcb5e81a7f9ac9a22
  • Fix handling of PlaceHolderVars in nestloop parameter management. If we use a PlaceHolderVar from the outer relation in an inner indexscan, we need to reference the PlaceHolderVar as such as the value to be passed in from the outer relation. The previous code effectively tried to reconstruct the PHV from its component expression, which doesn't work since (a) the Vars therein aren't necessarily bubbled up far enough, and (b) it would be the wrong semantics anyway because of the possibility that the PHV is supposed to have gone to null at some point before the current join. Point (a) led to "variable not found in subplan target list" planner errors, but point (b) would have led to silently wrong answers. Per report from Roger Niederland. http://git.postgresql.org/pg/commitdiff/7e3bf99baa18524de6ef1492cb3057314da97e68
  • Fix inline_set_returning_function() to allow multiple OUT parameters. inline_set_returning_function failed to distinguish functions returning generic RECORD (which require a column list in the RTE, as well as run-time type checking) from those with multiple OUT parameters (which do not). This prevented inlining from happening. Per complaint from Jay Levitt. Back-patch to 8.4 where this capability was introduced. http://git.postgresql.org/pg/commitdiff/515e813543dad5464c1a226fd068fd4daf26a7f9
  • Improve comments for TSLexeme data structure. Mostly, clean up long-ago pgindent damage. http://git.postgresql.org/pg/commitdiff/a0d2f05a0d433ab68ec378744ff920562a5ef681
  • Fix bogus code in contrib/ tsearch dictionary examples. Both dict_int and dict_xsyn were blithely assuming that whatever memory palloc gives back will be pre-zeroed. This would typically work for just about long enough to run their regression tests, and no longer :-(. The pre-9.0 code in dict_xsyn was even lamer than that, as it would happily give back a pointer to the result of palloc(0), encouraging its caller to access off the end of memory. Again, this would just barely fail to fail as long as memory contained nothing but zeroes. Per a report from Rodrigo Hjort that code based on these examples didn't work reliably. http://git.postgresql.org/pg/commitdiff/e3e3087d8717c26cd1c4581ba29274ac214eb816
  • Don't assume that a tuple's header size is unchanged during toasting. This assumption can be wrong when the toaster is passed a raw on-disk tuple, because the tuple might pre-date an ALTER TABLE ADD COLUMN operation that added columns without rewriting the table. In such a case the tuple's natts value is smaller than what we expect from the tuple descriptor, and so its t_hoff value could be smaller too. In fact, the tuple might not have a null bitmap at all, and yet our current opinion of it is that it contains some trailing nulls. In such a situation, toast_insert_or_update did the wrong thing, because to save a few lines of code it would use the old t_hoff value as the offset where heap_fill_tuple should start filling data. This did not leave enough room for the new nulls bitmap, with the result that the first few bytes of data could be overwritten with null flag bits, as in a recent report from Hubert Depesz Lubaczewski. The particular case reported requires ALTER TABLE ADD COLUMN followed by CREATE TABLE AS SELECT * FROM ... or INSERT ... SELECT * FROM ..., and further requires that there be some out-of-line toasted fields in one of the tuples to be copied; else we'll not reach the troublesome code. The problem can only manifest in this form in 8.4 and later, because before commit a77eaa6a95009a3441e0d475d1980259d45da072, CREATE TABLE AS or INSERT/SELECT wouldn't result in raw disk tuples getting passed directly to heap_insert --- there would always have been at least a junkfilter in between, and that would reconstitute the tuple header with an up-to-date t_natts and hence t_hoff. But I'm backpatching the tuptoaster change all the way anyway, because I'm not convinced there are no older code paths that present a similar risk. http://git.postgresql.org/pg/commitdiff/039680affb1b925e8e5c9578b0ab05fa326452fe
  • Un-break horology regression test. Adjust ill-considered timezone-dependent tests added in commit 8a3d33c8e6c681d512f79af4a521ee0c02befcef so that they won't fail on DST transition days. Per all-pink buildfarm. http://git.postgresql.org/pg/commitdiff/362f731dde94b10f8a01e80fddd2bf99c4f66587

Magnus Hagander a poussé :

Simon Riggs a poussé :

Bruce Momjian a poussé :

Peter Eisentraut a poussé :

Robert Haas a poussé :

Heikki Linnakangas a poussé :

Andrew Dunstan a poussé :

Alvaro Herrera a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Scott Mead sent in two revisions of a patch to see some context around <IDLE> IN TRANSACTION.
  • Shigeru HANADA sent in another revision of the patch to add a PostgreSQL FDW.
  • Peter Eisentraut sent in another revision of the patch to enable psql to switch automatically between normal and \x mode depending on the width of the output.
  • Robert Haas sent in three revisions of a patch to drop the "=>" notation from hstore.
  • Andrew Dunstan sent in another revision of the patch to add an --exclude-table-data option to pg_dump.
  • KaiGai Kohei sent in two more revisions of the patch to fix certain types of information leaks in VIEWs.
  • Andrew Dunstan sent in another revision of the patch to add a \setenv command to psql.
  • KaiGai Kohei sent in a patch to add checks for INSERT permission on new tables constructed by SELECT INTO or CREATE TABLE AS.
  • Simon Riggs and Robert Haas traded revisions of a patch to skip busy pages during VACUUM.
  • Alvaro Herrera sent in another revision of the patch to add foreign key locks.
  • Pavan Deolasee sent in a patch to store hot members of PGPROC out of band, a performance optimization.
  • Gabriele Bartolini sent in a WIP patch to allow arrays to be foreign keys to scalar primary keys.
  • Tomas Vondra sent in a patch that would allow optional "cleaning" of queries tracked in pg_stat_statements, compressing the result and making it more readable.
  • Greg Smith sent in a patch adds a new function to the pageinspect extension for measuring total free space, in either tables or indexes. It returns the free space as a percentage, so higher numbers mean more bloat.
  • J Smith sent in a fix to some corner-case bugs in the unaccent module.

par N Bougain le samedi 12 novembre 2011 à 14h14

Nouvelles hebdomadaires de PostgreSQL - 30 octobre 2011

L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Magnus Hagander a poussé :

Alvaro Herrera a poussé :

Tom Lane a poussé :

  • Change FK trigger creation order to better support self-referential FKs. When a foreign-key constraint references another column of the same table, row updates will queue both the PK's ON UPDATE action and the FK's CHECK action in the same event. The ON UPDATE action must execute first, else the CHECK will check a non-final state of the row and possibly throw an inappropriate error, as seen in bug #6268 from Roman Lytovchenko. Now, the firing order of multiple triggers for the same event is determined by the sort order of their pg_trigger.tgnames, and the auto-generated names we use for FK triggers are "RI_ConstraintTrigger_NNNN" where NNNN is the trigger OID. So most of the time the firing order is the same as creation order, and so rearranging the creation order fixes it. This patch will fail to fix the problem if the OID counter wraps around or adds a decimal digit (eg, from 99999 to 100000) while we are creating the triggers for an FK constraint. Given the small odds of that, and the low usage of self-referential FKs, we'll live with that solution in the back branches. A better fix is to change the auto-generated names for FK triggers, but it seems unwise to do that in stable branches because there may be client code that depends on the naming convention. We'll fix it that way in HEAD in a separate patch. Back-patch to all supported branches, since this bug has existed for a long time. http://git.postgresql.org/pg/commitdiff/58958726ffaec8d1a5d6a63f648443886fde8a21
  • Change FK trigger naming convention to fix self-referential FKs. Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and "RI_ConstraintTrigger_c_NNNN" for FK check triggers. This ensures the action trigger fires first in self-referential cases where the very same row update fires both an action and a check trigger. This change provides a non-probabilistic solution for bug #6268, at the risk that it could break client code that is making assumptions about the exact names assigned to auto-generated FK triggers. Hence, change this in HEAD only. No need for forced initdb since old triggers continue to work fine. http://git.postgresql.org/pg/commitdiff/1e3b21dd5e1070d301153690c1751bef74f03fa4
  • Improve planner's ability to recognize cases where an IN's RHS is unique. If the right-hand side of a semijoin is unique, then we can treat it like a normal join (or another way to say that is: we don't need to explicitly unique-ify the data before doing it as a normal join). We were recognizing such cases when the RHS was a sub-query with appropriate DISTINCT or GROUP BY decoration, but there's another way: if the RHS is a plain relation with unique indexes, we can check if any of the indexes prove the output is unique. Most of the infrastructure for that was there already in the join removal code, though I had to rearrange it a bit. Per reflection about a recent example in pgsql-performance. http://git.postgresql.org/pg/commitdiff/3e4b3465b6345b75659e8f897976d4c810408762
  • Typo fixes. expect -> except, noted by Andrew Dunstan. Also, "cannot" seems more readable here than "can not", per David Wheeler. http://git.postgresql.org/pg/commitdiff/bf82013631e32436c9abb23fee8be0a4ce46b3dd
  • Add simple script to check for right recursion in Bison grammars. We should generally use left-recursion not right-recursion to parse lists. Bison hasn't got any built-in way to check for this type of inefficiency, and I didn't find anything on the net in a quick search, so I wrote a little Perl script to do it. Add to src/tools/ so we don't have to re-invent this wheel next time we wonder if we're doing anything stupid. Currently, the only place that seems to need fixing is plpgsql's stmt_else production, so the problem doesn't appear to be common enough to warrant trying to include such a test in our standard build process. If we did want to do that, we'd need a way to ignore some false positives, such as a_expr := '-' a_expr http://git.postgresql.org/pg/commitdiff/756a4ed5ad3e57c26a247234de371a6ca21806cd
  • Avoid recursion while processing ELSIF lists in plpgsql. The original implementation of ELSIF in plpgsql converted the construct into nested simple IF statements. This was prone to stack overflow with long ELSIF lists, in two different ways. First, it's difficult to generate the parsetree without using right-recursion in the bison grammar, and that's prone to parser stack overflow since nothing can be reduced until the whole list has been read. Second, we'd recurse during execution, thus creating an unnecessary risk of execution-time stack overflow. Rewrite so that the ELSIF list is represented as a flat list, scanned via iteration not recursion, and generated through left-recursion in the grammar. Per a gripe from Håvard Kongsgård. http://git.postgresql.org/pg/commitdiff/051d1ba7a02d0e8930adf228d60e8a044b9fcadb
  • Update docs to point to the timezone library's new home at IANA. The recent unpleasantness with copyrights has accelerated a move that was already in planning. http://git.postgresql.org/pg/commitdiff/ece12659cf1695d318445b837b36edc15b6f25d6
  • De-parallelize ecpg build some more. Make sure ecpg/include/ is rebuilt before the other subdirectories, so that ecpg_config.h is up to date. This is not likely to matter during production builds, only development, so no back-patch. http://git.postgresql.org/pg/commitdiff/74812624f263a58789e894a643161c9148112f62
  • Fix assorted bogosities in cash_in() and cash_out(). cash_out failed to handle multiple-byte thousands separators, as per bug #6277 from Alexander Law. In addition, cash_in didn't handle that either, nor could it handle multiple-byte positive_sign. Both routines failed to support multiple-byte mon_decimal_point, which I did not think was worth changing, but at least now they check for the possibility and fall back to using '.' rather than emitting invalid output. Also, make cash_in handle trailing negative signs, which formerly it would reject. Since cash_out generates trailing negative signs whenever the locale tells it to, this last omission represents a fail-to-reload-dumped-data bug. IMO that justifies patching this all the way back. http://git.postgresql.org/pg/commitdiff/7609239f3e8d1cf8818c186c0cfa39145bf6425a
  • Further improvement of make_greater_string. Make sure that it considers all the possibilities that the old code did, instead of trying only one possibility per character position. To keep the runtime in bounds, instead tweak the character incrementers to not try every possible multibyte character code. Remove unnecessary logic to restore the old character value on failure. Additional comment and formatting cleanup. http://git.postgresql.org/pg/commitdiff/eb5834d5af5fd094da2f61a874d9d0ec9c870f6c
  • Support more locale-specific formatting options in cash_out(). The POSIX spec defines locale fields for controlling the ordering of the value, sign, and currency symbol in monetary output, but cash_out only supported a small subset of these options. Fully implement p/n_sign_posn, p/n_cs_precedes, and p/n_sep_by_space per spec. Fix up cash_in so that it will accept all these format variants. Also, make sure that thousands_sep is only inserted to the left of the decimal point, as required by spec. Per bug #6144 from Eduard Kracmar and discussion of bug #6277. This patch includes some ideas from Alexander Lakhin's proposed patch, though it is very different in detail. http://git.postgresql.org/pg/commitdiff/6743a878a4e9442a9846d8c270e5028e514d44f3

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

  • Fix the number of lwlocks needed by the "fast path" lock patch. It needs one lock per backend or auxiliary process - the need for a lock for each aux processes was not accounted for in NumLWLocks(). No-one noticed, because the three locks needed for the three aux processes fit into the few extra lwlocks we allocate for 3rd party modules that don't call RequestAddinLWLocks() (NUM_USER_DEFINED_LWLOCKS, 4 by default). http://git.postgresql.org/pg/commitdiff/cbf65509bb59694412286239fe6db409060f8d69

Robert Haas a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Fujii Masao and Jun Ishiduka traded revisions of the patch to allow taking a base backup from a hot standby.
  • Shigeru HANADA sent in two revisions of patches for a PostgreSQL FDW, along with some generic helper functions and new documentation on how to write FDWs.
  • Heikki Linnakangas sent in another revision of the patch to add multiple tuples at once in COPY.
  • Simon Riggs sent in two revisions of a patch to fix an issue where hot backup fails at rsync fails at pg_clog when under load.
  • Kerem Kat sent in another revision of the patch to add CORRESPONDING TO set operations.
  • Pavel Stehule sent in another revision of the patch that allows PL/pgsql to make arrays of any %TYPE declared.
  • Alexander Korotkov sent in another revision of the patch to collect statistics for array columns.
  • Robert Haas sent in a couple of patches he was using to analyze the slowness of COUNT(*) in the index-only scan case.
  • Simon Riggs sent in two revisions of a patch to speed up hot standbys in the subtransaction case.
  • Robert Haas sent in a patch to speed up unlogged tables.
  • Robert Haas sent in a patch that initializes each PGPROC's myProcLocks just once at postmaster startup rather than every time the PGPROC is handed out to a backend.

par N Bougain le samedi 12 novembre 2011 à 13h58

lundi 7 novembre 2011

Base-sql.fr

Install postgresql avec yum et modif de port !

Bonjour,

J’ ai constaté une petite coquille avec l’installation de postgresql 9.0.x avec Yum sur Centos (par exemple).
On a beau changer de port au niveau du postgresql.conf ça ne change en aucun cas le port d’écoute :)
Il faut aller dans le /etc/init.d/postresql-9.0 et modifier le PGPORT à la main.

Et il ne faut pas oublier qu’en cas de mise à jour le port par défaut (5432) reviendra dans le fichier de démarrage, donc à remodifier.

Voilà je voulais juste le signaler ^^

par kenrio le lundi 7 novembre 2011 à 16h26

lundi 31 octobre 2011

Dimitri Fontaine

Extensions en simple SQL

La conférence européenne à Amsterdam était un très bon évènement de la communauté, avec une organisation impeccable dans un hôtel accueillant. J'ai eu le plaisir d'y parler des extensions et de leur usage dans le cadre du développement applicatif « interne », sous le titre Extensions are good for business logic.

L'idée de ma présentation, que la plupart d'entre vous a loupé je suppose (en tout cas je n'avais qu'une petite poignée de français dans la salle, et j'espère avoir des lecteurs qui n'étaient pas à Amsterdam), l'idée est d'utiliser les mécanismes offerts par les extensions afin de maintenir le code PL que vous utilisez en production.

Il s'agit la plupart du temps de procédures qui implémentent une partie de la logique métier de vos applications, mais si proche des données que cela termine en base directement : c'est une bonne chose, en particulier depuis PostgreSQL 9.1. Cette version propose en effet une gestion assez complète des extensions.

Il s'agit de réaliser un empaquetage de vos procédures en suivant la documentation en ligne et son chapitre 35.15. Empaqueter des objets dans une extension. Une fois cela fait, il est alors possible de déployer votre ensemble de procédure stockée avec la commande CREATE EXTENSION mesprocs;, et ensuite la commande psql \dx vous permet de lister les extensions installées et leur numéro de version.

Les mises à jours sont également gérées avec une commande SQL dédiée, il s'agit alors de ALTER EXTENSION mesprocs UPDATE [TO version];. Il suffit de fournir des scripts intermédiaires nommés par exemple mesprocs--1.0--1.1.sql et mesprocs--1.1--1.2.sql et PostgreSQL saura comment passer de 1.0 à 1.1.

Voilà, vous savez presque tout de ma présentation à Amsterdam et vous pouvez retrouver le reste sur le support proposé en début d'article. Bien sûr je n'ai pas reproduit ici les questions intéressantes qui m'ont été posées, une bonne partie d'entre elles sont venues enrichir ma liste de Noël pour les extensions. Si vous voulez être sûr de trouver cela sous votre sapin, cependant, le meilleur moyen est encore de m'en parler : sponsoriser les développement Open Source est une belle démarche :)

par dim@tapoueh.org (Dimitri Fontaine) le lundi 31 octobre 2011 à 13h22

samedi 29 octobre 2011

Guillaume Lelarge

Sortie de pgsnap 0.7.0

Comme promis, voici la nouvelle version de pgsnap. Dans les nouveautés, la compatibilité avec PostgreSQL 9.1, un rapport sur les journaux de transactions et un autre sur les tailles d'index, la possibilité de trier tous les tableaux (merci jquery), sans parler de la possibilité d'ajouter automatiquement un répertoire contenant le rapport de toutes les bases de données.

Bref, du bon, mais rien de majeur non plus. La 0.8 devrait proposer plus de nouveaux rapports, et il est tout à fait possible qu'elle arrive rapidement (ie, avant la fin de l'année).

J'en ai profité pour faire une page wiki sur github qui récapitule quelques informations sur cet outil.

par Guillaume Lelarge le samedi 29 octobre 2011 à 17h43

jeudi 27 octobre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 23 octobre 2011

PGDay.SoCal est au programme de SCALE10X (exposition Linux dans le sud de la Californie) tenue au LAX Hilton Hotel de Los Angeles, le vendredi 20 janvier 2012. Veuillez envoyer vos propositions de conférences à pgday-submissions CHEZ googlegroups POINT com. https://sites.google.com/site/pgdayla/

Le programme de Postgres Brazil 2011 est en ligne : http://pgbr.postgresql.org.br/2011/programacao.en.php

Jim Mlodgenski présente "Visualizing PostgreSQL Data with Google Web Toolkit" (Visualisation de données PostgreSQL avec Google Web Toolkit) avec le NYCPUG le 25 octobre 2011 à 18h30. Détails et RSVP ci-dessous : http://www.nycpug.org/events/36991582/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Magnus Hagander a poussé :

Tom Lane a poussé :

  • Fix pg_dump to dump casts between auto-generated types. The heuristic for when to dump a cast failed for a cast between table rowtypes, as reported by Frédéric Rejol. Fix it by setting the "dump" flag for such a type the same way as the flag is set for the underlying table or base type. This won't result in the auto-generated type appearing in the output, since setting its objType to DO_DUMMY_TYPE unconditionally suppresses that. But it will result in dumpCast doing what was intended. Back-patch to 8.3. The 8.2 code is rather different in this area, and it doesn't seem worth any risk to fix a corner case that nobody has stumbled on before. http://git.postgresql.org/pg/commitdiff/b246207bd7b553317fd90d7aefd9520eed27609a
  • Remove unnecessary AssertMacro() to suppress gcc 4.6 compiler warning. There's no particular value in doing AssertMacro((tup) != NULL) in front of code that's certain to crash anyway if tup is NULL. And if "tup" is actually the address of a local variable, gcc 4.6 whinges about it. That's arguably pretty broken on gcc's part, but we might as well remove the useless test to silence the warnings. This gets rid of all the -Waddress warnings in the backend; there are some in libpq and psql that are a bit harder to avoid. http://git.postgresql.org/pg/commitdiff/7c19e0446c049dd41aed62fa398cd809017adf5e
  • Reject empty pg_hba.conf files. An empty HBA file is surely an error, since it means there is no way to connect to the server. We've not heard identifiable reports of people actually doing that, but this will also close off the case Thom Brown just complained of, namely pointing hba_file at a directory. (On at least some platforms with some directories, it will read as an empty file.) Perhaps this should be back-patched, but given the lack of previous complaints, I won't add extra work for the translators. http://git.postgresql.org/pg/commitdiff/e27f52f3a1814e646733f51b8c24547371bef3eb
  • Suppress -Wunused-result warnings about write() and fwrite(). This is merely an exercise in satisfying pedants, not a bug fix, because in every case we were checking for failure later with ferror(), or else there was nothing useful to be done about a failure anyway. Document the latter cases. http://git.postgresql.org/pg/commitdiff/aa90e148ca70a235897b1227f1a7cd1c66bc5368
  • Suppress remaining -Waddress warnings from recent gcc versions. Still an exercise in satisfying pedants. http://git.postgresql.org/pg/commitdiff/e331c60ea727f998eb1023e8a2c468692d10032e
  • Fix memory leak in tab completion. This was introduced in commit e49ad77ff958b380ea6fa08c72e2dce97ac56c6b. Fixed in another, more future-proof way in HEAD. http://git.postgresql.org/pg/commitdiff/790fa1fdd8bb32e2e9055dd47d76c2382c51c84a
  • Rewrite tab completion's previous-word fetching for more sanity. Make it return empty strings when there are no more words to the left of the current position, instead of sometimes returning NULL and other times returning copies of the leftmost word. Also, fetch the words in one scan, rather than the previous wasteful approach of starting from scratch for each word. Make the code a bit harder to break when someone decides we need more words of context, too. (There was actually a memory leak here, because whoever added prev6_wd neglected to free it.) http://git.postgresql.org/pg/commitdiff/dce92c6d6abe302c58fd4e4221efed54913aefdb
  • Simplify and improve ProcessStandbyHSFeedbackMessage logic. There's no need to clamp the standby's xmin to be greater than GetOldestXmin's result; if there were any such need this logic would be hopelessly inadequate anyway, because it fails to account for within-database versus cluster-wide values of GetOldestXmin. So get rid of that, and just rely on sanity-checking that the xmin is not wrapped around relative to the nextXid counter. Also, don't reset the walsender's xmin if the current feedback xmin is indeed out of range; that just creates more problems than we already had. Lastly, don't bother to take the ProcArrayLock; there's no need to do that to set xmin. Also improve the comments about this in GetOldestXmin itself. http://git.postgresql.org/pg/commitdiff/b4a0223d008d7c2c9824d846e22b664b2f09cf6e
  • More cleanup after failed reduced-lock-levels-for-DDL feature. Turns out that use of ShareUpdateExclusiveLock or ShareRowExclusiveLock to protect DDL changes had gotten copied into several places that were not touched by either of Simon's original patches for the feature, and thus neither he nor I thought to revert them. (Indeed, it appears that two of these uses were committed *after* the reversion, which just goes to show that git merging is no panacea.) Change these places to use AccessExclusiveLock again. If we ever manage to resurrect that feature, we're going to have to think a bit harder about how to keep lock level usage in sync for DDL operations that aren't within the AlterTable infrastructure. Two of these bugs are only in HEAD, but one is in the 9.1 branch too. Alvaro Herrera found one of them, I found the other two. http://git.postgresql.org/pg/commitdiff/5ac5980744149f062ec599015ffe7a7689dd117b
  • Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements. http://git.postgresql.org/pg/commitdiff/f9c92a5a3ead738c7de0dffa203a92b4d2fec413
  • Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane http://git.postgresql.org/pg/commitdiff/bb446b689b6681eb57a8a50605e119743190c4db
  • Don't trust deferred-unique indexes for join removal. The uniqueness condition might fail to hold intra-transaction, and assuming it does can give incorrect query results. Per report from Marti Raudsepp, though this is not his proposed patch. Back-patch to 9.0, where both these features were introduced. In the released branches, add the new IndexOptInfo field to the end of the struct, to try to minimize ABI breakage for third-party code that may be examining that struct. http://git.postgresql.org/pg/commitdiff/0f39d5050dc0dce99258381f33f1832c437aff85
  • Improve git_changelog's handling of inconsistent commit orderings. Use the CommitDate not the AuthorDate, as the former is representative of the order in which things went into the main repository, and the latter isn't very; we now have instances where the AuthorDate is as much as a month before the patch really went in. Also, get rid of the "commit order inversions" heuristic, which turns out not to do anything very desirable. Instead we just print commits in strict timestamp order, interpreting the "timestamp" of a merged commit as its timestamp on the newest branch it appears in. This fixes some cases where very ancient commits were being printed relatively early in the report. http://git.postgresql.org/pg/commitdiff/7299778a958112b0339ab29365ba0d654bd5d21c
  • Make psql support tab completion of EXECUTE <prepared-statement-name>. Andreas Karlsson, reviewed by Josh Kupershmidt http://git.postgresql.org/pg/commitdiff/8140c1bcf355c4925114cc127de476384053dc96

Robert Haas a poussé :

Heikki Linnakangas a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Kerem Kat sent in two more revisions of a patch to add CORRESPONDING set operations.
  • Jun Ishiduka sent in two more revisions of the patch to allow taking a base backup from a hot standby.
  • KaiGai Kohei sent in two more revisions of the patch to unite DROP into a single framework.
  • Fujii Masao sent in another revision of the patch to fix an issue where it is possible to drop transactions in streaming replication.
  • Florian Pflug sent in a patch to document how to build the docs on OS/X with MacPorts.
  • Etsuro Fujita sent in another revision of the patch to allow running ANALYZE on CSV files via the FDW supplied module interface.
  • Wojciech Muła and Pavel Stehule traded new revisions of the patch to allow arrays of %TYPE in PL/pgsql.

par N Bougain le jeudi 27 octobre 2011 à 23h43

lundi 24 octobre 2011

Damien Clochard

PG Day France 2012 : première réunion

Tout d'abord un grand merci aux personnes qui ont répondu à l'appel lancé en juin pour organiser une conférence dédiée à PostgreSQL en France et en 2012.

PostgreSQL Conference Europe 2011 vient de s'achever à Amsterdam et même si je n'étais pas présent cette année, les échos que j'en reçois confirment que ces conférences sont des moments essentiels pour la vie d'une communauté.

Bref après les PG Day France de 2008 et 2009, il est temps de relancer la machine !

La première réunion du groupe organisateur est prévue :

  • le lundi 31 octobre 2011
  • de 20h à 21h tapantes
  • sur le canal IRC #pgday.fr du réseau freenode.

(Contactez moi si vous ne pouvez pas être présent ou si vous avez du mal à nous rejoindre sur IRC )

Participer à l'organisation d'une conférence est vraiment une superbe occasion d'entrer en contact avec la communauté PostgreSQL. En guise d'exemples, voici quelques taches à réaliser :

  • sur place : recherche d'une salle, d'un traiteur, etc.
  • le jour J : accueil des participants
  • à distance : gérer le call for paper
  • à distance : faire partie du comité de sélection des interventions
  • à distance : animer le site web, le compte twitter, etc.
  • le jour J : captation audio/video des confs

Pour l'instant, la date et le lieu ne sont pas fixés. On sait juste que ça se passera en France en 2012 Tout le reste est à inventer....

Par ailleurs, à toute fin utile précisons que :

a/ Cet évènement est soutenu par l'association PostgreSQLFr

b/ L'organisation de l’événement est ouverte aux individus et aux sociétés qui ne font pas partie de l'asso

c/ L'association est prête a engager des moyens financiers et administratifs pour aider à la réalisation de la conférence. Les éventuelles pertes seront supportées par l'asso. En contrepartie, les éventuels bénéfices seront gérés par l'asso. La trésorière de l'association pourra à tout moment opposer un veto à une dépense jugée inutile.

par damien le lundi 24 octobre 2011 à 22h28

vendredi 21 octobre 2011

Guillaume Lelarge

pgconf.eu 2011, Amsterdam, jour 4

Vendredi a commencé assez difficilement : Gilles Darold à qui j'ai dû expliqué très rapidement et très mal l'enregistrement des personnes à l'accueil, pas de portable pour la conférence de Jean-Paul Argudo, et le portable de Luis Ochoa qui ne voulait pas fonctionner avec le rétro-projecteur... bref, la conférence donnée par Luis et moi-même a commencé un brin en retard et un peu sur les chapeaux de roue. Elle s'est néanmoins très bien passée. Bruce Momjian faisait partie de l'audience et a été impressionné par ce que Luis a été capable de faire en trois à quatre mois. Une personne lui avait posé une question mardi dernier, à savoir avait-on un outil libre capable de faire de la conception graphique de bases de données. Et il avait répondu non. Mais maintenant, il pourra répondre oui :) Bref. Le public était plutôt restreint pour nous (environ 10 personnes) ainsi que pour Jean-Paul, mais les retours ont été très bons. Le reste du public était dans la salle principale où Simon Riggs parlait du futur de PostgreSQL. Et, à ma grande surprise, il a parlé de réplication bi-directionnelle (autrement dit du maître/maître). Oui. Miam :-D

Gevik devait être le responsable des conférences de la deuxième salle mais il tenait beaucoup à assister à la conférence de Greg Smith sur les benchmarks. J'ai donc pris son poste pour qu'il puisse aller écouter Greg. De mon côté, ça m'a permis d'assister à la conférence de Jehan-Guillaume de Rorthais et de Leonardo Augusto Sapiras. Ils ont parlé de l'ajout d'un système de plugins dans phpPgAdmin, travail effectué pendant le GSoC 2011 par Leonardo. Très sympa, et certainement des plugins très intéressants vont arriver rapidement (allez, rapidement, de tête, un database designer bien plus joli que celui de pgAdmin (oui, je suis jaloux) et pgpooladmin).

DSC_7557.JPG

Ensuite, Michael Meskes a parlé de la possibilité de remplacer une base de données propriétaire par PostgreSQL. Vu son expérience avec Informix, Oracle et SQL Server, il a donné quelques informations très utiles et quelques arguments qui jouent clairement en la faveur de PostgreSQL. Personnellement, j'ai aussi été très content de rencontrer ce monsieur dont j'entends parler depuis... facilement dix ans, et que je n'avais encore jamais rencontré.

Concernant les autres conférences de ce matin, j'avais déjà vu celle de Magnus Hagander lors de char(11). Une excellente conférence qui ouvre les yeux sur les possibilités offertes par le protocole de réplication.

L'après-midi a été beaucoup plus calme. Elle a commencé avec trois conférences. Vu le manque d'audience, la conférence de Jean-Paul a été annulée. Il semble que les conférences en français n'ont pas marché du tout et il faudra éviter cette erreur l'année prochaine.

J'étais moi-même à la conférence de Stephen Frost. Très intéressante, elle passait sur tous les points qui concernent la recherche des requêtes lentes ainsi que leur correction. Simple et bien vu. Par un conférencier très à l'aise, et très rapide. La dernière conférence était donnée par Selena Deckelmann (« Managing terabytes »), que j'avais déjà vu grâce à une vidéo sur internet (les slides sont sur http://www.slideshare.net/selenamarie/managing-terabytes et la vidéo sur http://www.casttv.com/video/v9n1zxu/postgresql-screencasts-managing-terabytes-video ... désolé la vidéo que j'avais était meilleure mais je n'arrive pas à retrouver le lien). Une conférence plutôt intéressante.

Pour la fin, Ed Boyajian, CEO d'EDB, devait intervenir mais dû à un problème avec les douanes américaines, il n'a pas pu venir. Du coup, il a fait un petit discours via Skype pendant 10/15 minutes. Puis, Bruce Momjian a donné la conférence finale. Il a expliqué ce qu'il avait vu, entendu pendant ces quelques jours. Ce n'est rien de dire qu'il m'a de nouveau motivé à m'impliquer encore davantage dans cette communauté et je pense ne pas avoir été le seul :)

DSC_7569.JPG

La journée s'est terminée avec les remerciements du staff aux conférenciers et aux participants.

Que dire de plus. C'était une extraordinaire expérience, des journées formidables et j'espère que je serais là l'année prochaine pour en profiter de nouveau.

par Guillaume Lelarge le vendredi 21 octobre 2011 à 19h19

jeudi 20 octobre 2011

Guillaume Lelarge

pgconf.eu 2011, Amsterdam, jour 3

Je devais rester à l'accueil le matin mais Dave étant bizarrement aussi à l'accueil, j'en ai profité pour prendre des photos des conférenciers, ainsi que d'écouter un peu chaque conférence.

Cédric Villemain a fait une conférence en français sur Slony et Londiste. Il a pu ainsi annoncer la sortie de la dernière version de Slony, la 2.1, sortie survenue vers 2h du matin (heure locale) ce même jour. C'est de l'instantané :) Étant une conférence en français à Amsterdam, il y a eu peu de participants malheureusement.

Pendant ce temps-là, Greg Smith donnait sa conférence sur le VACUUM. Grosse audience et encore un gros succès pour Greg.

DSC_7501.JPG

Mais j'ai préféré aller voir la conférence de Poojan Kumar, de la société vmware pour en savoir plus sur leur offre dans le "cloud". J'avoue avoir été assez impressionné par leur système de clonage et de sauvegarde.

DSC_7497.JPG

Les trois conférences suivantes étaient encore une fois très intéressantes :

  • Heikki Linnakangas sur SSI

DSC_7503.JPG

DSC_7504.JPG

  • Jon Erdman sur la création de sauvegarde fichiers pour des tests ou de la pré-production

DSC_7507.JPG

Personnellement, je serais plutôt allé à la conférence de Heikki. Je n'ai pas non plus eu l'occasion de voir les autres conférences de cette matinée. J'ai entendu des commentaires très positifs sur la conférence d'Alexander Korotkov, un étudiant GSoC qui présentait le résultat de son travail sur la création rapide d'index GiST. Travail qui devrait d'ailleurs être incorporé à la version 9.2. Cette dernière semble de plus en plus fortement orienté performances.

L'après-midi a commencé avec une conférence de Selena. Gros succès, impossible de fermer la porte de sa salle, les gens préféraient rester assis par terre, y compris à la porte pour l'écouter. Impressionnant :)

DSC_7519.JPG

Gianni Ciolli a eu aussi beaucoup de monde pour sa conférence sur les requêtes CTE en écriture.

DSC_7524.JPG

Jonathan Katz a présenté l'écriture d'extensions Django pour PostgreSQL, qui a eu malheureusement moins de succès, alors que le contenu est vraiment intéressant.

DSC_7520.JPG

DSC_7528.JPG

Ensuite a eu lieu ma propre conférence. 50 minutes sur les vues statistiques et sur ce qu'on peut en faire. J'ai eu entre 20 et 30 personnes, peut-être un peu plus. Les gens avaient l'air intéressé, notamment par les graphiques et le moyen d'y arriver. J'ai fini bien en avance, ce qui a permis quelques questions/réponses suivies d'une démo sur l'utilisation de la vue pg_locks (un peu hors sujet mais intéressant malgré tout).

Après ma conférence, j'ai eu l'occasion de discuter longuement avec Pavel Gollub, développeur principal des outils PostgreSQL proposés par microolap. Notamment, il a fait une démo très impressionnante de Database Designer. C'est vraiment le grand avantage de ce genre d'événements : rencontrer les gens qui créent et qui utilisent PostgreSQL. C'est très informatif, pratiquement plus que les conférences elles-mêmes.

La dernière conférence était les « Lightning talks ». C'est un ensemble de petites conférences. Chaque personne intéressé a cinq minutes maximum pour présenter une idée, un concept, un projet.

DSC_7547.JPG

Cela peut ne pas être sérieux du tout, comme celle réalisée par Selena, ou au contraire très technique, ce qu'a fait Hans-Juergen.

Après cela, il a fallu attendre 19h pour aller à la soirée sponsorisée par Heroku : beaucoup de boissons, beaucoup de snacks et encore plus de discussions. Merci Heroku :)

par Guillaume Lelarge le jeudi 20 octobre 2011 à 20h49

mercredi 19 octobre 2011

Guillaume Lelarge

pgconf.eu 2011, Amsterdam, jour 2

Première journée des conférences standards, donc gros rush à l'enregistrement. Néanmoins, cela se passe bien. Le fait d'avoir déjà enregistré les personnes venu hier a certainement bien aidé.

DSC_7466.JPG

Magnus Hagander a fait son discours de bienvenue, puis a introduit Ram Mohan de la société Affilias. Ram venait faire la conférence d'ouverture de pgconf.eu 2011. C'est un exercice difficile qui demande beaucoup de travail et je dois dire que Ram s'en est très bien sorti. C'est intéressant, factuel et en même temps motivant. Motivant pour utiliser PostgreSQL mais aussi pour participer à la communauté.

DSC_7470.JPG

Après cette conférence et la pause-café, les conférences ont commencé. Difficile de ne pas trouver une conférence intéressante quand trois salles proposent une conférence chacune pratiquement toutes les heures. En fait, il a surtout été reproché que le choix était difficile à cause de la qualité des conférences et du fait que beaucoup se déroulaient en parallèle. C'est un problème bon à avoir car cela indique que nous ne nous sommes pas trompés dans le choix des conférences.

Malheureusement, faisant parti des organisateurs, je n'ai pas pu voir beaucoup de conférences entières. Je me suis baladé le matin entre les différentes salles de conférences pour prendre des photos. Magnus a eu beaucoup de succès avec sa conférence sur les nouveautés de la version 9.1 : beaucoup d'informations car beaucoup de nouvelles fonctionnalités, avec le point de vue d'un des développeurs majeurs de PostgreSQL.

DSC_7478.JPG

Dave Page a d'ailleurs été dans le détail d'une de ses nouvelles fonctionnalités : SQL/MED.

DSC_7483.JPG

J'avais déjà vu cette conférence, elle est vraiment bien pour comprendre comment implémenter un Foreign Data Wrapper. La conférence de Vincent Picavet sur PostGIS a aussi été bien suivie : PostGIS est vraiment une extension importante dans le monde de PostgreSQL.

DSC_7486.JPG

Quant à Gianni Ciolli, il a osé aborder les fonctions de fenêtrage avec sa bonne humeur habituelle. Difficile quand il s'agit d'un sujet aussi complexe que celui-là.

DSC_7488.JPG

L'après-midi, étant responsable d'une salle de conférences, j'ai pu voir les conférences qui s'y déroulaient entièrement. Gilles Darold a ouvert le bal avec une conférence sur ora2pg, malheureusement en français, ce qui a fait que peu de personnes y ont assisté. Pourtant, beaucoup voulaient venir mais une fois qu'ils ont compris que c'était en français seulement, ça a réduit nettement l'audience.

DSC_7492.JPG

Gilles a expliqué l'historique du projet, les dernières fonctionnalités, les problèmes qu'il a pu rencontré, et plein d'autres choses encore. Ensuite, nous avons eu Marc Balmer.

DSC_7493.JPG

Il a montré un exemple d'utilisation du mécanisme LISTEN/NOTIFY de PostgreSQL. Se faisant, il a démontré l'intérêt de ce mécanisme très particulier. C'était très convaincant. Enfin, Stephen Frost est venu parler de l'organisation de la revue de patchs. Stephen participe beaucoup au développement de PostgreSQL, il a notamment beaucoup contribué à l'intégration de la gestion des rôles. Du coup, sa vision du développement aidait bien à appréhender le besoin de revue de patchs, y compris par des personnes ayant une connaissance faible du langage C. Comme il le disait, mieux vaut que plusieurs personnes relisent les patchs, ça permet de détecter plus rapidement les éventuels bugs qui s'y trouvent.

DSC_7494.JPG

Du coup, je n'ai pas vu du tout les autres conférences. Bruce Momjian a expliqué l'optimiseur de requêtes. J'avais déjà vu cette conférence lors d'un autre événement et le succès qu'il a eu cette fois-ci ne m'étonne pas du tout. Greg Smith et Simon Riggs ont parlé de réplication. Là-aussi, grosse audience, gros succès. Je serais bien allé à la conférence de Steve Singer (« Troubleshooting Slony »), ainsi qu'à celle de Stefan Kaltenbrunner (« Metering the smart way, a smart grid for the datacenter »). Je n'ai jamais eu l'occasion de les voir et j'en ai entendu beaucoup de bien.

La soirée a commencé à l'hôtel. Dalibo a sponsorisé une première heure de boissons et snacks gratuits, et OpenSCG a sponsorisé une deuxième heure. Après ça, nous sommes partis avec les personnes de Skype à la recherche d'un restaurant.

par Guillaume Lelarge le mercredi 19 octobre 2011 à 20h49

mardi 18 octobre 2011

Guillaume Lelarge

pgconf.eu 2011, Amsterdam, jour 1

Cette journée est une journée consacrée aux mini-formations. Bruce Momjian a fait une journée sur l'administration de PostgreSQL. Greg Smith a fait lui-aussi une journée entière sur les performances. Enfin, Magnus Hagander et moi-même avons fait une demi-journée chacun sur la réplication. Magnus a présenté la réplication interne de PostgreSQL et je me suis occupé de la réplication proposée par Slony. Les formations les plus populaires étaient évidemment celles de Bruce et de Greg mais je suis assez content de voir que quelques personnes étaient intéressées par Slony.

Ma formation s'est bien passée. C'était la première fois que j'en faisais une en anglais mais après un petit stress inévitable, ça s'est bien mieux passé que ce que je craignais.

par Guillaume Lelarge le mardi 18 octobre 2011 à 20h47

Nicolas Thauvin

Quand PostgreSQL n'a plus d'espace disque à manger

Voilà donc une question intéressante, comment se comporte PostgreSQL face à un système de fichier plein ? Un peu d'expérimentation est nécessaire pour se rassurer...

On crée deux systèmes de fichiers de faible taille pour les tests. Le premier stockera PGDATA, ainsi qu'une base de données nommée db_data. Le second sera le tablesapce ts1, dans lequel on créera une base de données db_ts1.

L'objectif est de montrer que seules les transactions modifiant des objets stockés sur des systèmes de fichier plein sont affectées, c'est pourquoi on a besoin de plusieurs tablespaces

Les binaires se trouvent dans /home/pgsql/postgresql-9.0.4, PGDATA dans /home/pgsql/postgresql-9.0.4/data, et le tablespace dans /home/pgsql/postgresql-9.0.4/ts1. On a donc monté et donné la propriété des deux filesystèmes à orgrim, que fera tourner PostgreSQL :

# df -h
...
/dev/mapper/sys-pg1   504M   54M  425M  12% /home/pgsql/postgresql-9.0.4/data
/dev/mapper/sys-pg2   504M   17M  462M   4% /home/pgsql/postgresql-9.0.4/ts1
...

# cd /home/pgsql/postgresql-9.0.4/
# chown orgrim: data ts1
# chmod 700 data ts1

Le cluster est préparé avec l'environnement suivant :

$ env | grep PG
PGPORT=5904
PGDATABASE=postgres
PGDATA=/home/pgsql/postgresql-9.0.4/data
PATH=/home/pgsql/postgresql-9.0.4/bin:$PATH

On lance donc initdb, puis on crée les bases avec le tablespace :

$ initdb
$ psql
psql (9.0.4)
Type "help" for help.

postgres=# CREATE DATABASE db_data;
CREATE DATABASE
postgres=# CREATE TABLESPACE ts1 LOCATION '/home/pgsql/postgresql-9.0.4/ts1';
CREATE TABLESPACE
postgres=# CREATE DATABASE db_ts1 TABLESPACE ts1;
CREATE DATABASE

Ensuite, on se connecte à la base de données db_ts1 et on y crée une base qui permettra de remplir le tablespace ts1 :

$ while ((1)); do psql -c "INSERT INTO t SELECT generate_series(1, 1000) AS i;" db_ts1; done

Au bout, d'un moment le système de fichier du tablespace est plein et tout requête générant des écritures sort en erreur avec un message de cette forme :

ERROR:  could not extend file "pg_tblspc/16385/PG_9.0_201008051/16386/16390": wrote only 4096 of 8192 bytes at block 58438
HINT:  Check free disk space.

Ensuite, on essaye avec le répertoire PGDATA, on crée donc une table dans la base db_data :

$ psql db_data
psql (9.0.4)
Type "help" for help.

db_data=# CREATE TABLE t (i int);
CREATE TABLE

De la même façon, on remplit cette table jusqu'à épuisement de l'espace libre :

$ while ((1)); do psql -c "INSERT INTO t SELECT generate_series(1, 1000) AS i;" db_data; done

Résultat, les requêtes sortent en erreur de la même façon. On a peut-être de la chance ici, le filesystem contenant pg_xlog, les problèmes pourraient être pis.

Il est également possible de remplir le système de fichiers de journaux de transactions, ce qui est problématique du fait que chaque transaction est écrite ici tout tablespace confondu. On vide donc les deux bases :

$ psql db_ts1
psql (9.0.4)
Type "help" for help.

db_ts1=# TRUNCATE t;
TRUNCATE TABLE

$ psql db_data
psql (9.0.4)
Type "help" for help.

db_data=# TRUNCATE t;
TRUNCATE TABLE

Et on place le paramètre checkpoint_segments à 300, valeur démesurée par rapport à la place disponible dans PGDATA.

Après un reload, on refait alors le test de remplissage de la base db_ts1, qui assure que les journaux de transactions seuls remplissent PGDATA.

Le serveur PostgreSQL s'arrête parce qu'il ne peut écrire le journal de transaction :

PANIC:  could not write to file "pg_xlog/xlogtemp.8795": No space left on device
STATEMENT:  INSERT INTO t SELECT generate_series(1, 1000) AS i;
LOG:  server process (PID 8795) was terminated by signal 6: Aborted
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
LOG:  all server processes terminated; reinitializing

Il redémarre illico, mais le problème persiste :

FATAL:  the database system is in recovery mode
LOG:  database system was interrupted; last known up at 2011-10-12 00:01:40 CEST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  consistent recovery state reached at 0/5FDB7480
LOG:  redo starts at 0/5AA57D68
LOG:  could not open file "pg_xlog/000000010000000000000074" (log file 0, segment 116): No such file or directory
LOG:  redo done at 0/73FFFF90
LOG:  last completed transaction was at log time 2011-10-12 00:05:11.710639+02
PANIC:  could not write to file "pg_xlog/xlogtemp.8797": No space left on device
LOG:  startup process (PID 8797) was terminated by signal 6: Aborted
LOG:  aborting startup due to startup process failure

Le seul moyen de se sortir de cette situation est d'utiliser les 5% d'espace libre du filesystème réservés au super utilisateur, de baisser la valeur de checkpoint_segments à une valeur évitant le filesystem full, les checkpoints successif supprimeront les fichiers en trop.

Lorsqu'on a plus besoin de 5% réservés, il ne faut pas oublier de remettre la réservation.

Enfin, ce cas le plus critique peut arriver assez facilement lorsqu'on a de l'archivage, si le serveur ne peut plus archiver les fichiers WAL, alors il les conserve, un filesystem full sur un espace d'archivage peut donc être transmis au serveur...

par Orgrim le mardi 18 octobre 2011 à 11h31

lundi 17 octobre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 16 octobre 2011

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

  • La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre : http://2011.pgconf.eu/
  • Le PG-Day Denver 2011 aura lieu le vendredi 21 octobre 2011 dans le campus Auraria près de Denver, Colorado : http://pgday.consistentstate.com/
  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Bruce Momjian a poussé :

Robert Haas a poussé :

Tom Lane a poussé :

  • Rearrange the implementation of index-only scans. This commit changes index-only scans so that data is read directly from the index tuple without first generating a faux heap tuple. The only immediate benefit is that indexes on system columns (such as OID) can be used in index-only scans, but this is necessary infrastructure if we are ever to support index-only scans on expression indexes. The executor is now ready for that, though the planner still needs substantial work to recognize the possibility. To do this, Vars in index-only plan nodes have to refer to index columns not heap columns. I introduced a new special varno, INDEX_VAR, to mark such Vars to avoid confusion. (In passing, this commit renames the two existing special varnos to OUTER_VAR and INNER_VAR.) This allows ruleutils.c to handle them with logic similar to what we use for subplan reference Vars. Since index-only scans are now fundamentally different from regular indexscans so far as their expression subtrees are concerned, I also chose to change them to have their own plan node type (and hence, their own executor source file). http://git.postgresql.org/pg/commitdiff/a0185461dd94c8d31d8d55a7f2839b0d2f172ab9
  • Consider index-only scans even when there is no matching qual or ORDER BY. By popular demand. http://git.postgresql.org/pg/commitdiff/600d3206d1b3f8b540397b79905486a536ac7f78
  • Generate index-only scan tuple descriptor from the plan node's indextlist. Dept. of second thoughts: as long as we've got that tlist hanging around anyway, we can apply ExecTypeFromTL to it to get a suitable descriptor for the ScanTupleSlot. This is a nicer solution than the previous one because it eliminates some hard-wired knowledge about btree name_ops, and because it avoids the somewhat shaky assumption that we needn't set up the scan tuple descriptor in EXPLAIN_ONLY mode. It doesn't change what actually happens at run-time though, and I'm still a bit nervous about that. http://git.postgresql.org/pg/commitdiff/cb6771fb32cbdb11c8d84b7d62ee940bdba38d52
  • Add comment on why pulling data from a "name" index column can't crash. It's been bothering me for several days that pretending that the cstring data stored in a btree name_ops column is really a "name" Datum could lead to reading past the end of memory. However, given the current memory layout used for index-only scans in the btree code, a crash is in fact not possible. Document that so we don't break it. I have not thought of any other solutions that aren't fairly ugly too, and most of them lose the functionality of index-only scans on name columns altogether, so this seems like the way to go. http://git.postgresql.org/pg/commitdiff/8c8ba6d11b06e5a8b9fe5653a1cd17c437af5f7b
  • Improve documentation of psql's \q command. The documentation neglected to explain its behavior in a script file (it only ends execution of the script, not psql as a whole), and failed to mention the long form \quit either. http://git.postgresql.org/pg/commitdiff/80c6409c2bb9417c059603f0b5b88209517c7593
  • Throw a useful error message if an extension script file is fed to psql. We have seen one too many reports of people trying to use 9.1 extension files in the old-fashioned way of sourcing them in psql. Not only does that usually not work (due to failure to substitute for MODULE_PATHNAME and/or @extschema@), but if it did work they'd get a collection of loose objects not an extension. To prevent this, insert an \echo ... \quit line that prints a suitable error message into each extension script file, and teach commands/extension.c to ignore lines starting with \echo. That should not only prevent any adverse consequences of loading a script file the wrong way, but make it crystal clear to users that they need to do it differently now. Tom Lane, following an idea of Andrew Dunstan's. Back-patch into 9.1 ... there is not going to be much value in this if we wait till 9.2. http://git.postgresql.org/pg/commitdiff/458857cc9d7d00711b272a0dabbcb591b506d6b8
  • Don't mark auto-generated types as extension members. Relation rowtypes and automatically-generated array types do not need to have their own extension membership dependency entries. If we create such then it becomes more difficult to remove items from an extension, and it's also harder for an extension upgrade script to make sure it duplicates the dependencies created by the extension's regular installation script. I changed the code in such a way that this happened in commit 988cccc620dd8c16d77f88ede167b22056176324, I think because of worries about the shell-type-replacement case; but that cure was worse than the disease. It would only matter if one extension created a shell type that was replaced with an auto-generated type in another extension, which seems pretty far-fetched. Better to make this work unsurprisingly in normal cases. Report and patch by Robert Haas, comment adjustments by me. http://git.postgresql.org/pg/commitdiff/7b96519fe24b6a675b2cd39ed3b89302b8f1fedb
  • Fix typo in dummy_seclabel documentation. dummy_label -> dummy_seclabel. Thom Brown http://git.postgresql.org/pg/commitdiff/de1bf53a254a2a832ddbc46395e9af2b918d9302
  • Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane http://git.postgresql.org/pg/commitdiff/23610daf8af0f5b468b5c0d4774295cc02ad30a9
  • Measure the number of all-visible pages for use in index-only scan costing. Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here. http://git.postgresql.org/pg/commitdiff/e6858e665731c0f56d3ecc9fbb245c32d24f8ef7
  • Measure the number of all-visible pages for use in index-only scan costing. Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here. http://git.postgresql.org/pg/commitdiff/e6858e665731c0f56d3ecc9fbb245c32d24f8ef7
  • Fix bugs in information_schema.referential_constraints view. This view was being insufficiently careful about matching the FK constraint to the depended-on primary or unique key constraint. That could result in failure to show an FK constraint at all, or showing it multiple times, or claiming that it depended on a different constraint than the one it really does. Fix by joining via pg_depend to ensure that we find only the correct dependency. Back-patch, but don't bump catversion because we can't force initdb in back branches. The next minor-version release notes should explain that if you need to fix this in an existing installation, you can drop the information_schema schema then re-create it by sourcing $SHAREDIR/information_schema.sql in each database (as a superuser of course). http://git.postgresql.org/pg/commitdiff/d26e1ebaf5f8f59c27327e8fd810fa4b26431a1f
  • Marginal improvements to documentation of plpgsql's OPEN cursor statement. Rearrange text to improve clarity, and add an example of implicit reference to a plpgsql variable in a bound cursor's query. Byproduct of some work I'd done on the "named cursor parameters" patch before giving up on it. http://git.postgresql.org/pg/commitdiff/0898d71f66ed884af726556ac9ffc8081dddc757
  • Teach btree to handle ScalarArrayOpExpr quals natively. This allows "indexedcol op ANY(ARRAY[...])" conditions to be used in plain indexscans, and particularly in index-only scans. http://git.postgresql.org/pg/commitdiff/9e8da0f75731aaa7605cf4656c21ea09e84d2eb1
  • Fix collate.linux.utf8 expected output for recent error message change. Noted by Jeff Davis. http://git.postgresql.org/pg/commitdiff/e661c3dfd320487aaa1d6223e732e00c1b5c3cc2
  • Avoid assuming that index-only scan data matches the index's rowtype. In general the data returned by an index-only scan should have the datatypes originally computed by FormIndexDatum. If the index opclasses use "storage" datatypes different from their input datatypes, the scan tuple will not have the same rowtype attributed to the index; but we had a hard-wired assumption that that was true in nodeIndexonlyscan.c. We'd already hacked around the issue for the one case where the types are different in btree indexes (btree name_ops), but this would definitely come back to bite us if we ever implement index-only scans in GiST. To fix, require the index AM to explicitly provide the tupdesc for the tuple it is returning. btree can just pass back the index's tupdesc, but GiST will have to work harder when and if it supports index-only scans. I had previously proposed fixing this by allowing the index AM to fill the scan tuple slot directly; but on reflection that seemed like a module layering violation, since TupleTableSlots are creatures of the executor. At least in the btree case, it would also be less efficient, since the tuple deconstruction work would occur even for rows later found to be invisible to the scan's snapshot. http://git.postgresql.org/pg/commitdiff/336c1d7a515b4d6de237679022d70082d7b69d9a

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Fujii Masao sent in another revision of the patch to unite recovery.conf and postgresql.conf.
  • Jun Ishiduka sent in four more revisions of the patch to allow taking a base backup from a hot standby.
  • Kyotaro HORIGUCHI sent in another revision of the patch to fix the issue where make_greater_string() does not return a string in some cases.
  • KaiGai Kohei sent in another revision of the patch to rework DROP to use a unified infrastructure.
  • Heikki Linnakangas and Jeff Davis traded new revisions of the patch to add range types.
  • Fujii Masao sent in another revision of a patch to fix some conditions wich can cause loss of transactions in streaming replication.
  • Willy-Bas Loos sent in a patch to make it possible to record automatically the time a table is created.
  • Florian Pflug sent in a patch to fix an issue in walsender when calling out to do_pg_stop_backup.
  • Alexander Korotkov sent in another revision of the patch to collect frequency statistics for arrays.
  • Jan Urbanski sent in a patch implementing the usage of SPI cursors in PL/Python.
  • Kerem Kat sent in another revision of a patch adding CORRESPONDING set operations.

par N Bougain le lundi 17 octobre 2011 à 22h18

Guillaume Lelarge

pgconf.eu 2011, Amsterdam, jour 0

Après 3h30 de voyage en train, nous sommes enfin arrivés à Amsterdam pour les quatre jours de conférences sur PostgreSQL organisés par PostgreSQL Europe.

Ça fait maintenant un an qu'une dizaine de personnes travaillent, semaine après semaine, sur cet événement. Faisant parti de ces dix personnes, il est très plaisant d'en voir maintenant le résultat.

Dave Page et Magnus Hagander sont déjà à l'hôtel quand nous y arrivons. Nous les rejoignons rapidement pour leur dire bonjour, puis partons visiter la ville de notre côté pendant deux petites heures.

Au retour, il a fallu préparer les sacs que nous donnerons le lendemain aux participants, ainsi que les badges. Le travail s'est terminé à 20h. Nous sommes tous partis manger dans le centre-ville d'Amsterdam, et nous avons terminé la soirée au bar de l'hôtel.

par Guillaume Lelarge le lundi 17 octobre 2011 à 20h44

dimanche 16 octobre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 9 octobre 2011

La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre. Les inscriptions sont encore ouvertes : http://2011.pgconf.eu/registration/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

  • La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre : http://2011.pgconf.eu/
  • Le PG-Day Denver 2011 aura lieu le vendredi 21 octobre 2011 dans le campus Auraria près de Denver, Colorado : http://pgday.consistentstate.com/
  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • ProcedureCreate neglected to record dependencies on default expressions. Thus, an object referenced in a default expression could be dropped while the function remained present. This was unaccountably missed in the original patch to add default parameters for functions. Reported by Pavel Stehule. http://git.postgresql.org/pg/commitdiff/76074fcaa04fb5d35e8cf7716587440e3d075d50
  • Remove the custom_variable_classes parameter. This variable provides only marginal error-prevention capability (since it can only check the prefix of a qualified GUC name), and the consensus is that that isn't worth the amount of hassle that maintaining the setting creates for DBAs. So, let's just remove it. With this commit, the system will silently accept a value for any qualified GUC name at all, whether it has anything to do with any known extension or not. (Unqualified names still have to match known built-in settings, though; and you will get a WARNING at extension load time if there's an unrecognized setting with that extension's prefix.) There's still some discussion ongoing about whether to tighten that up and if so how; but if we do come up with a solution, it's not likely to look anything like custom_variable_classes. http://git.postgresql.org/pg/commitdiff/1a00c0ef5368bb7b8ddcb3cf279df36577918ac4
  • Remember the source GucContext for each GUC parameter. We used to just remember the GucSource, but saving GucContext too provides a little more information --- notably, whether a SET was done by a superuser or regular user. This allows us to rip out the fairly dodgy code that define_custom_variable used to use to try to infer the context to re-install a pre-existing setting with. In particular, it now works for a superuser to SET a extension's SUSET custom variable before loading the associated extension, because GUC can remember whether the SET was done as a superuser or not. The plperl regression tests contain an example where this is useful. http://git.postgresql.org/pg/commitdiff/9f5836d224e876399dfdd7d6d4343300dbc2f664
  • Add sourcefile/sourceline data to EXEC_BACKEND GUC transmission files. This oversight meant that on Windows, the pg_settings view would not display source file or line number information for values coming from postgresql.conf, unless the backend had received a SIGHUP since starting. In passing, also make the error detection in read_nondefault_variables a tad more thorough, and fix it to not lose precision on float GUCs (these changes are already in HEAD as of my previous commit). http://git.postgresql.org/pg/commitdiff/4bcb82a7d590afa16507f9089bd68ef4bcebebb1
  • Fix uninitialized-variable bug. http://git.postgresql.org/pg/commitdiff/fa56a0c3e01c175695e932e6cdc2c6915df5adc6
  • Improve define_custom_variable's handling of pre-existing settings. Arrange for any problems with pre-existing settings to be reported as WARNING not ERROR, so that we don't undesirably abort the loading of the incoming add-on module. The bad setting is just discarded, as though it had never been applied at all. (This requires a change in the API of set_config_option. After some thought I decided the most potentially useful addition was to allow callers to just pass in a desired elevel.) Arrange to restore the complete stacked state of the variable, rather than cheesily reinstalling only the active value. This ensures that custom GUCs will behave unsurprisingly even when the module loading operation occurs within nested subtransactions that have changed the active value. Since a module load could occur as a result of, eg, a PL function call, this is not an unlikely scenario. http://git.postgresql.org/pg/commitdiff/41e461d36fb1ef78494429f28ea4b72c759f419d
  • Improve and simplify CREATE EXTENSION's management of GUC variables. CREATE EXTENSION needs to transiently set search_path, as well as client_min_messages and log_min_messages. We were doing this by the expedient of saving the current string value of each variable, doing a SET LOCAL, and then doing another SET LOCAL with the previous value at the end of the command. This is a bit expensive though, and it also fails badly if there is anything funny about the existing search_path value, as seen in a recent report from Roger Niederland. Fortunately, there's a much better way, which is to piggyback on the GUC infrastructure previously developed for functions with SET options. We just open a new GUC nesting level, do our assignments with GUC_ACTION_SAVE, and then close the nesting level when done. This automatically restores the prior settings without a re-parsing pass, so (in principle anyway) there can't be an error. And guc.c still takes care of cleanup in event of an error abort. The CREATE EXTENSION code for this was modeled on some much older code in ri_triggers.c, which I also changed to use the better method, even though there wasn't really much risk of failure there. Also improve the comments in guc.c to reflect this additional usage. http://git.postgresql.org/pg/commitdiff/ba6f629326be365a3124dc80aa5d303e2b0bf46b
  • Support index-only scans using the visibility map to avoid heap fetches. When a btree index contains all columns required by the query, and the visibility map shows that all tuples on a target heap page are visible-to-all, we don't need to fetch that heap page. This patch depends on the previous patches that made the visibility map reliable. There's a fair amount left to do here, notably trying to figure out a less chintzy way of estimating the cost of an index-only scan, but the core functionality seems ready to commit. Robert Haas and Ibrar Ahmed, with some previous work by Heikki Linnakangas. http://git.postgresql.org/pg/commitdiff/a2822fb9337a21f98ac4ce850bb4145acf47ca27
  • Fix brain fade in cost estimation for index-only scans. visibility_fraction should not be applied to regular indexscans. Noted by Cédric Villemain. http://git.postgresql.org/pg/commitdiff/b324384f6bd5d661efeddb83d7f607781e96947d
  • Note that index-only scans can affect idx_tup_fetch. An index-only scan that avoids heap fetches will increment idx_tup_read but not idx_tup_fetch. http://git.postgresql.org/pg/commitdiff/c78d8cd1464bc6b69fdc72f9ce51407c89554ece
  • Prevent index-only scans in stats regression test. This bollixes the test because it's expecting to see the idx_tup_fetch counter increase, which won't happen if heap fetches were avoided by use of an index-only scan. Per buildfarm results. While at it, let's just make sure that enable_seqscan and enable_indexscan are ON for this test ... http://git.postgresql.org/pg/commitdiff/45401c1c25fe1ef14bf68089de86bcb5cce9f453
  • Improve index-only scans to avoid repeated access to the index page. We copy all the matched tuples off the page during _bt_readpage, instead of expensively re-locking the page during each subsequent tuple fetch. This costs a bit more local storage, but not more than 2*BLCKSZ worth, and the reduction in LWLock traffic is certainly worth that. What's more, this lets us get rid of the API wart in the original patch that said an index AM could randomly decline to supply an index tuple despite having asserted pg_am.amcanreturn. That will be important for future improvements in the index-only-scan feature, since the executor will now be able to rely on having the index data available. http://git.postgresql.org/pg/commitdiff/cbfa92c23c3924d53889320cdbe26f23ee23e40c

Alvaro Herrera a poussé :

  • Use callbacks in SlruScanDirectory for the actual action. Previously, the code assumed that the only possible action to take was to delete files behind a certain cutoff point. The async notify code was already a crock: it used a different "pagePrecedes" function for truncation than for regular operation. By allowing it to pass a callback to SlruScanDirectory it can do cleanly exactly what it needs to do. The clog.c code also had its own use for SlruScanDirectory, which is made a bit simpler with this. http://git.postgresql.org/pg/commitdiff/09e196e4539a70c51e828abcfe48dee3efd312d8

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

Robert Haas a poussé :

Magnus Hagander a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Simon Riggs sent in two more revisions of the patch to separate checkpointing and background writing into distinct components.
  • Royce Ausburn sent in two revisions of a patch to enable monitoring unremovable tuples.
  • Heikki Linnakangas sent in another revision of a patch to fix some socket issues on HP-UX.
  • Fujii Masao sent in another revision of a patch to fix a bug in recovery.
  • Fujii Masao sent in another revision of a patch to add a pg_last_xact_insert_timestamp column.
  • Alex Hunsaker sent in two more revisions of a patch to do some encoding checking for PL/Perl inputs.
  • Pavel Stehule sent in a patch which returns the number of rows processed by COPY.
  • KaiGai Kohei sent in two more revisions of the patch to rework DROP into a single framework.
  • Pavel Stehule sent in two revisions of a patch to implement CHECK FUNCTION and CHECK TRIGGER.
  • Alex Hunsaker sent in two more revisions of a patch to allow non-inheritable CHECK constraints.
  • Alex Hunsaker and Robert Haas traded revisions of a patch to fix ALTER TABLE ONLY ... DROP CONSTRAINT.
  • Marti Raudsepp sent in another revision of a patch to log crashed backends.
  • Kyotaro HORIGUCHI sent in a patch to endure that make_greater_string() returns a string.
  • Simon Riggs sent in two revisions of a patch to prevent duplicate checkpoints.
  • Etsuro Fujita sent in another revision of a patch to collect statistics on foreign tables.
  • Yeb Havinga sent in another revision of a patch that enables cursors with named parameters.
  • Julien Tachoires sent in a WIP patch which enables moving TOAST tables to a different tablespace.
  • Kevin Grittner sent in another revision of the patch to optimize box_penalty.
  • KaiGai Kohei sent in another revision of the patch to fix some leaks in VIEWs.
  • Jun Ishiduka sent in another revision of the patch to allow creating a backup from a hot standby.

par N Bougain le dimanche 16 octobre 2011 à 22h55

lundi 10 octobre 2011

Dimitri Fontaine

Extensions, applications

La conférence PostgreSQL annuelle en Europe a lieu la semaine prochaine à Amsterdam, et j'espère que vous avez déjà vos billets, car cette édition s'annonce comme un très bon millésime !

Je présenterai donc comment utiliser les extensions, le titre en anglais est Extensions are good for business logic, et l'idée est de voir comment exploiter les extensions afin de mieux gérer vos mises à jours en bases de données.

Le cycle de vie des bases de données en production inclue souvent l'utilisation d'une base de développement où le schéma évolue au rythme des besoins des développeurs, et de temps en temps on consolide une partie de ces modifications (dans des rollouts, scripts contenant principalement des DDL) afin de les déployer en production — si possible avec une étape intermédiaire en préproduction, tout de même.

Savoir ce qui est déployé en développement et comment en retirer le script à jouer en production peut être parfois fastidieu. Quand ce n'est pas le cas, c'est que le travail a été fait en amont, ce qui est le signe d'une bonne organisation, avec les surcoûts que l'on peut imaginer.

Les extensions telles que présentes dans PostgreSQL 9.1 vous permettent de mieux gérer ce genre de cas, en optimisant le surcoût : il ne disparaît pas, mais devient opérationnel plutôt que de rester une charge d'organisation.

Allez, je vous laisse maintenant, je dois me préparer pour la conférence :)

par dim@tapoueh.org (Dimitri Fontaine) le lundi 10 octobre 2011 à 08h35

jeudi 6 octobre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 2 octobre 2011

Inscriptions spéciales "lèves-tôts" (pas cher ! pas cher !) disponibles pour le PGDay.IT : http://blog.2ndquadrant.com/en/2011/09/pgday-it-2011-early-bird-registrations-open.html

La liste des conférenciers pour le PGBR2011 a été publiée : http://pgbr.postgresql.org.br/2011/palestrantes.en.php

Les nouveautés des produits dérivés

PostgreSQL Local

  • La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre : http://2011.pgconf.eu/
  • Le PG-Day Denver 2011 aura lieu le vendredi 21 octobre 2011 dans le campus Auraria près de Denver, Colorado : http://pgday.consistentstate.com/
  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • Use a fresh copy of query_list when making a second plan in GetCachedPlan. The code path that tried a generic plan, didn't like it, and then made a custom plan was mistakenly passing the same copy of the query_list to the planner both times. This doesn't work too well for nontrivial queries, since the planner tends to scribble on its input. Diagnosis and fix by Yamamoto Takashi. http://git.postgresql.org/pg/commitdiff/21fb95da46bce8de3e149707c680d489b8a5ffb0
  • Speed up array element assignment in plpgsql by caching type information. Cache assorted data in the PLpgSQL_arrayelem struct to avoid repetitive catalog lookups over multiple executions of the same statement. Pavel Stehule http://git.postgresql.org/pg/commitdiff/16762b519c9421ad5f1e373b1d89b0f2f6568769
  • Allow snapshot references to still work during transaction abort. In REPEATABLE READ (nee SERIALIZABLE) mode, an attempt to do GetTransactionSnapshot() between AbortTransaction and CleanupTransaction failed, because GetTransactionSnapshot would recompute the transaction snapshot (which is already wrong, given the isolation mode) and then re-register it in the TopTransactionResourceOwner, leading to an Assert because the TopTransactionResourceOwner should be empty of resources after AbortTransaction. This is the root cause of bug #6218 from Yamamoto Takashi. While changing plancache.c to avoid requesting a snapshot when handling a ROLLBACK masks the problem, I think this is really a snapmgr.c bug: it's lower-level than the resource manager mechanism and should not be shutting itself down before we unwind resource manager resources. However, just postponing the release of the transaction snapshot until cleanup time didn't work because of the circular dependency with TopTransactionResourceOwner. Fix by managing the internal reference to that snapshot manually instead of depending on TopTransactionResourceOwner. This saves a few cycles as well as making the module layering more straightforward. predicate.c's dependencies on TopTransactionResourceOwner go away too. I think this is a longstanding bug, but there's no evidence that it's more than a latent bug, so it doesn't seem worth any risk of back-patching. http://git.postgresql.org/pg/commitdiff/57eb009092684e6e1788dd0dae641ccee1668b10
  • Fix window functions that sort by expressions involving aggregates. In commit c1d9579dd8bf3c921ca6bc2b62c40da6d25372e5, I changed things so that the output of the Agg node that feeds the window functions would not list any ungrouped Vars directly. Formerly, for example, the Agg tlist might have included both "x" and "sum(x)", which is not really valid if "x" isn't a grouping column. If we then had a window function ordering on something like "sum(x) + 1", prepare_sort_from_pathkeys would find no exact match for this in the Agg tlist, and would conclude that it must recompute the expression. But it would break the expression down to just the Var "x", which it would find in the tlist, and then rebuild the ORDER BY expression using a reference to the subplan's "x" output. Now, after the above-referenced changes, "x" isn't in the Agg tlist if it's not a grouping column, so that prepare_sort_from_pathkeys fails with "could not find pathkey item to sort", as reported by Bricklen Anderson. The fix is to not break down Aggrefs into their component parts, but just treat them as irreducible expressions to be sought in the subplan tlist. This is definitely OK for the use with respect to window functions in grouping_planner, since it just built the tlist being used on the same basis. AFAICT it is safe for other uses too; most of the other call sites couldn't encounter Aggrefs anyway. http://git.postgresql.org/pg/commitdiff/269c5dd2f46e3490da05d5dd5dad07828df281d9
  • Take sepgsql regression tests out of the regular regression test mechanism. Because these tests require root privileges, not to mention invasive changes to the security configuration of the host system, it's not reasonable for them to be invoked by a regular "make check" or "make installcheck". Instead, dike out the Makefile's knowledge of the tests, and change chkselinuxenv (now renamed "test_sepgsql") into a script that verifies the environment is workable and then runs the tests. It's expected that test_sepgsql will only be run manually. While at it, do some cleanup in the error checking in the script, and do some wordsmithing in the documentation. http://git.postgresql.org/pg/commitdiff/cc4ff8742b99d3b20a52f529d03bbe802f4b0053
  • Update and extend the EXPLAIN-related documentation. I've made a significant effort at filling in the "Using EXPLAIN" section to be reasonably complete about mentioning everything that EXPLAIN can output, including the "Rows Removed" outputs that were added by Marko Tiikkaja's recent documentation-free patch. I also updated the examples to be consistent with current behavior; several of them were not close to what the current code will do. No doubt there's more that can be done here, but I'm out of patience for today. http://git.postgresql.org/pg/commitdiff/a32dd16459ae8fbc1e09607d7ed960b3dcce7dba
  • Fix index matching for operators with mixed collatable/noncollatable inputs. If an indexable operator for a non-collatable indexed datatype has a collatable right-hand input type, any OpExpr for it will be marked with a nonzero inputcollid (since having one collatable input is sufficient to make that happen). However, an index on a non-collatable column certainly doesn't have any collation. This caused us to fail to match such operators to their indexes, because indxpath.c required an exact match of index collation and clause collation. It seems correct to allow a match when the index is collation-less regardless of the clause's inputcollid: an operator with both noncollatable and collatable inputs could perhaps depend on the collation of the collatable input, but it could hardly expect the index for the noncollatable input to have that same collation. Per bug #6232 from Pierre Ducroquet. His example is specifically about "hstore ? text" but the problem seems quite generic. http://git.postgresql.org/pg/commitdiff/cb37c291060dd13b1a8ff61fceee09efcfbc34e1
  • Fix recursion into previously planned sub-query in examine_simple_variable. This code was looking at the sub-Query tree as seen in the parent query's RangeTblEntry; but that's the pristine parser output, and what we need to look at is the tree as it stands at the completion of planning. Otherwise we might pick up a Var that references a subquery that got flattened and hence has no RelOptInfo in the subroot. Per report from Peter Geoghegan. http://git.postgresql.org/pg/commitdiff/79edb2b1dc33166b576f51a8255a7614f748d9c9
  • Support GiST index support functions that want to cache data across calls. pg_trgm was already doing this unofficially, but the implementation hadn't been thought through very well and leaked memory. Restructure the core GiST code so that it actually works, and document it. Ordinarily this would have required an extra memory context creation/destruction for each GiST index search, but I was able to avoid that in the normal case of a non-rescanned search by finessing the handling of the RBTree. It used to have its own context always, but now shares a context with the scan-lifespan data structures, unless there is more than one rescan call. This should make the added overhead unnoticeable in typical cases. http://git.postgresql.org/pg/commitdiff/d22a09dc70f9830fa78c1cd1a3a453e4e473d354
  • Cache the result of makesign() across calls of gtrgm_penalty(). Since gtrgm_penalty() is usually called many times in a row with the same "newval" (to determine which item on an index page newval fits into best), the makesign() calculation is repetitious. It's expensive enough to make it worth caching the result, so do so. On my machine this is good for more than a 40% savings in the time needed to build a trigram index on /usr/share/dict/words. This is all per a suggestion of Heikki's. In passing, make some mostly-cosmetic improvements in the caching logic in the other functions in this file that rely on caching info in fn_extra. http://git.postgresql.org/pg/commitdiff/0a5d5a49d9965aa092e75ce31a88fbf5f05c5009
  • Improve generated column names for cases involving sub-SELECTs. We'll now use "exists" for EXISTS(SELECT ...), "array" for ARRAY(SELECT ...), or the sub-select's own result column name for a simple expression sub-select. Previously, you usually got "?column?" in such cases. Marti Raudsepp, reviewed by Kyotaro Horiugchi http://git.postgresql.org/pg/commitdiff/5ec6b7f1b87f0fa006b8e08a11cd4e99bcb67358
  • Restructure error handling in reading of postgresql.conf. This patch has two distinct purposes: to report multiple problems in postgresql.conf rather than always bailing out after the first one, and to change the policy for whether changes are applied when there are unrelated errors in postgresql.conf. Formerly the policy was to apply no changes if any errors could be detected, but that had a significant consistency problem, because in some cases specific values might be seen as valid by some processes but invalid by others. This meant that the latter processes would fail to adopt changes in other parameters even though the former processes had done so. The new policy is that during SIGHUP, the file is rejected as a whole if there are any errors in the "name = value" syntax, or if any lines attempt to set nonexistent built-in parameters, or if any lines attempt to set custom parameters whose prefix is not listed in (the new value of) custom_variable_classes. These tests should always give the same results in all processes, and provide what seems a reasonably robust defense against loading values from badly corrupted config files. If these tests pass, all processes will apply all settings that they individually see as good, ignoring (but logging) any they don't. In addition, the postmaster does not abandon reading a configuration file after the first syntax error, but continues to read the file and report syntax errors (up to a maximum of 100 syntax errors per file). The postmaster will still refuse to start up if the configuration file contains any errors at startup time, but these changes allow multiple errors to be detected and reported before quitting. Alexey Klyukin, reviewed by Andy Colson and av (Alexander ?) with some additional hacking by Tom Lane http://git.postgresql.org/pg/commitdiff/d56b3afc0376afe491065d9eca6440b3cc7b1346

Robert Haas a poussé :

Alvaro Herrera a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Peter Geoghegan sent in another revision of the patch to inline comparison operators.
  • Shigeru HANADA sent in another revision of the patch to display accumulated autovacuum cost.
  • Noah Misch and Alvaro Herrera traded patches to test for isolation failures.
  • Fujii Masao sent in two more revisions of the patch to enable making a base backup from a hot standby.
  • Bruce Momjian sent in two more revisions of a patch to fix testing for pg_upgrade.
  • Andreas Karlsson sent in a patch to allow for EXECUTE tab completion in psql.
  • Tom Lane sent in a WIP patch to break a circular dependency in snapshot management.
  • Marti Raudsepp sent in a patch to log crashed backends.
  • Brar Piening sent in another revision of the patch to support VS2010.
  • Joachim Wieland sent in another revision of the patch to enable exporting and synchronizing snapshots.
  • KaiGai Kohei sent in another revision of the patch to rework DROP into a single framework.
  • KaiGai Kohei sent in another revision of the patch to fix certain leaks in VIEWs.
  • Bruce Momjian sent in another revision of a patch to fix pg_upgrade.
  • Gurjeet Singh sent in a patch to remove savepointLevel from TransactionState.
  • Alvaro Herrera sent in a patch to make SLRU's truncate use callbacks.
  • Fujii Masao sent in a patch which prevents the creation of restartpoints by using rm_safe_restartpoint callback when a consistent state is not yet reached and the invalid-page table is not empty.
  • Kyotaro HORIGUCHI sent in another revision of the patch to add make_greater_string().
  • KaiGai Kohei sent in another revision of the patch to add object access hooks with argument support.
  • Jeff Davis sent in two more revisions of the patch to add range types.
  • Bruce Momjian sent in a patch which makes an empty string the default for external_pid_file in postgresql.conf to make it consistent with other defaults there.
  • Bruce Momjian sent in a patch to add a configuration directory setting for pg_upgrade.
  • Simon Riggs sent in another revision of a patch to separate the background writer process from the checkpointer.
  • Tom Lane sent in a WIP patch to remove custom variable classes for GUCs. There hadn't been a way to validate them anyhow, so now arbitrary GUCs are allowed.

par N Bougain le jeudi 6 octobre 2011 à 19h51

mardi 27 septembre 2011

Actualités PostgreSQL.fr

Nouvelles hebdomadaires de PostgreSQL - 25 septembre 2011

Les MAJ de sécurité 9.1.1, 9.0.5, 8.4.9, 8.3.16 et 8.2.22 sont disponibles. Installez-les dès que possible si vous êtes concernés. Détails ci-après : http://www.postgresql.org/about/news.1355

[ndt: annonce détaillée, en français : http://blog.postgresql.fr/index.php?post/2011/09/26/Nouvelles-versions-mineures]

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en septembre

PostgreSQL Local

  • PostgreSQL Conference West (#PgWest) aura lieu du 27 au 30 septembre 2011 au centre des conventions de San José (Californie, États-Unis) : http://www.postgresqlconference.org
  • La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre : http://2011.pgconf.eu/
  • Le PG-Day Denver 2011 aura lieu le vendredi 21 octobre 2011 dans le campus Auraria près de Denver, Colorado : http://pgday.consistentstate.com/
  • pgbr aura lieu à São Paulo (Brésil) les 3 & 4 novembre 2011 : http://pgbr.postgresql.org.br/
  • PGConf.DE 2011 est une conférence germanophone tenue le 11 novembre au musée industriel du Rhin à Oberhausen (Allemagne). L'appel à conférenciers est lancé : http://2011.pgconf.de/
  • La cinquième édition du PGDay italien (PGDay.IT 2011) aura lieu le 25 novembre à Prato : http://2011.pgday.it/
  • L'appel à conférenciers a été lancé pour le FLOSS UK, programmé du 20 au 22 mars 2012 à Edimbourg. La date limite de dépôt des candidatures est fixée au 18 novembre 2011 et les conférenciers sélectionnés seront informés avant le 25 novembre. Les propositions sont à envoyer à postgresql2012 AT flossuk POINT org. Plus d'informations via le lien suivant : http://www.flossuk.org/Events/Spring2012

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 reporting of newlocale() failures in CREATE COLLATION. The standardized errno code for "no such locale" failures is ENOENT, which we were just reporting at face value, viz "No such file or directory". Per gripe from Thom Brown, this might confuse users, so add an errdetail message to clarify what it means. Also, report newlocale() failures as ERRCODE_INVALID_PARAMETER_VALUE rather than using errcode_for_file_access(), since newlocale()'s errno values aren't necessarily tied directly to file access failures. http://git.postgresql.org/pg/commitdiff/37d4fd2b9d331076292201ab988fe54f09640850
  • Suppress "unused function" warning when not HAVE_LOCALE_T. Forgot to consider this case ... http://git.postgresql.org/pg/commitdiff/2562dcea811eb642e1c5442e1ede9fe268278157
  • Make EXPLAIN ANALYZE report the numbers of rows rejected by filter steps. This provides information about the numbers of tuples that were visited but not returned by table scans, as well as the numbers of join tuples that were considered and discarded within a join plan node. There is still some discussion going on about the best way to report counts for outer-join situations, but I think most of what's in the patch would not change if we revise that, so I'm going to go ahead and commit it as-is. Documentation changes to follow (they weren't in the submitted patch either). Marko Tiikkaja, reviewed by Marc Cousin, somewhat revised by Tom Lane http://git.postgresql.org/pg/commitdiff/f1972723654947f70409716757aa83f3d93c8fab
  • Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22. Man, we fixed a lotta bugs since April. http://git.postgresql.org/pg/commitdiff/7f70f35031b4dea40ab4fa20638befc430e8ebaa
  • Stamp 8.2.22, 8.3.16, 8.4.9, 9.0.5, 9.1.1.
  • Update win32tzlist.pl for the new location of our Windows timezone map. I wasn't aware of this script till Magnus Hagander mentioned it just now ... http://git.postgresql.org/pg/commitdiff/14a183261a1f9b15dc73ad34295d118ada538b5b
  • Fix our mapping of Windows timezones for Central America. We were mapping "Central America Standard Time" to "CST6CDT", which seems entirely wrong, because according to the Olson timezone database noplace in Central America observes daylight savings time on any regular basis --- and certainly not according to the USA DST rules that are implied by "CST6CDT". (Mexico is an exception, but they can be disregarded since they have a separate timezone name in Windows.) So, map this zone name to plain "CST6", which will provide a fixed UTC offset. As written, this patch will also result in mapping "Central America Daylight Time" to CST6. I considered hacking things so that would still map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those two names in separate entries. Since there's little evidence that any such zone name is used in the wild, much less that CST6CDT would be a good match for it, I'm not too worried about what we do with it. Per complaint from Pratik Chirania. http://git.postgresql.org/pg/commitdiff/4c5d837e69cf92e906acfa3000d848d4524beee9
  • Recognize self-contradictory restriction clauses for non-table relations. The constraint exclusion feature checks for contradictions among scan restriction clauses, as well as contradictions between those clauses and a table's CHECK constraints. The first aspect of this testing can be useful for non-table relations (such as subqueries or functions-in-FROM), but the feature was coded with only the CHECK case in mind so we were applying it only to plain-table RTEs. Move the relation_excluded_by_constraints call so that it is applied to all RTEs not just plain tables. With the default setting of constraint_exclusion this results in no extra work, but with constraint_exclusion = ON we will detect optimizations that we missed before (at the cost of more planner cycles than we expended before). Per a gripe from Gunnlaugur Þór Briem. Experimentation with his example also showed we were not being very bright about the case where constraint exclusion is proven within a subquery within UNION ALL, so tweak the code to allow set_append_rel_pathlist to recognize such cases. http://git.postgresql.org/pg/commitdiff/7741dd6590073719688891898e85f0cb73453159
  • Un-break compression of plain-text output format in pg_dump. pg_dump has historically understood -Z with no -F switch to mean that it should emit a gzip-compressed version of its plain text output. This got broken through a misunderstanding in the 9.1 patch that added directory output format. Restore the former behavior. Per complaint from Roger Niederland and diagnosis by Adrian Klaver. http://git.postgresql.org/pg/commitdiff/23fe7a74777eba01835389263418cbe8a546e772
  • Avoid unnecessary snapshot-acquisitions in BuildCachedPlan. I had copied-and-pasted a claim that we couldn't reach this point when dealing with utility statements, but that was a leftover from when the caller was required to supply a plan to start with. We now will go through here at least once when handling a utility statement, so it seems worth a check to see whether a snapshot is actually needed. (Note that analyze_requires_snapshot is quite a cheap test.) Per suggestion from Yamamoto Takashi. I don't think I believe that this resolves his reported assertion failure; but it's worth changing anyway, just to save a cycle or two. http://git.postgresql.org/pg/commitdiff/d5aa7a9fe68b2017362421bd853faeb8199a472c
  • Fully const-ify PQconnectdbParams, PQconnectStartParams, and PQpingParams. The keywords and values arguments of these functions are more properly declared "const char * const *" than just "const char **". Lionel Elie Mamane, reviewed by Craig Ringer http://git.postgresql.org/pg/commitdiff/2a571bc233821023afdf8729a3ae5071b2343f65

Robert Haas a poussé :

Peter Eisentraut a poussé :

Simon Riggs a poussé :

Magnus Hagander a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Jeff Davis sent in another revision of the patch to create range types.
  • Peter Geoghegan sent in three revisions of a patch to speed up comparators by inlining them.
  • Muhammad Asif sent in two revisions of a patch to fix an issue with BSD sockets on HP-UX.
  • Alexander Korotkov sent in two more revisions of the double sorting split patch.
  • Fujii Masao sent in another revision of the patch to allow doing a backup from a hot standby.
  • Pavel Stehule sent in another revision of the patch to remove unnecessary ccache search when an array variable is updated in PL/pgsql.
  • Yeb Havinga sent in a patch to refine dependency checking in EXTENSIONs.
  • Magnus Hagander sent in two revisions of a patch to make the TABLE command tab-complete both tables and views in psql. Before, it only tab-completed tables.
  • Magnus Hagander sent in a patch to add a call to posix_fadvise with POSIX_FADV_DONTNEED on all the files being read when doing a base backup, to help the kernel not to trash the filesystem cache.
  • Oleg Bartunov sent in another revision of the patch to enable space-partitioned GiST indexes.
  • Marti Raudsepp sent in another revision of the patch to cache stable expressions with constant arguments.
  • ITAGAKI Takahiro sent in a patch to allow COPY to support UTF8 files with a byte order mark (BOM).

par N Bougain le mardi 27 septembre 2011 à 05h51

lundi 26 septembre 2011

Guillaume Lelarge

pgsnap compatible avec PostgreSQL 9.1

Cela fait un moment que je n'avais pas travaillé sur pgsnap. J'ai pris le temps d'ajouter le support complet de la 9.1 ce soir. Je n'ai pas encore préparé une nouvelle version car j'aimerais y ajouter quelques fonctionnalités. En espérant que je me laisse le temps de le faire réellement...

Bref, en attendant, les sources sont disponibles sur le compte github de Dalibo.

Je me demande aussi si je ne devrais pas le recoder en C. Ce sera certainement plus amusant à faire que du PHP. Peut-être que la version 1.0 sera en C du coup :)

par Guillaume Lelarge le lundi 26 septembre 2011 à 21h25