FOSDEM PGDay est une conférence sur une journée qui se tiendra avant l'ouverture du FOSDEM à Bruxelles, le 1er février 2013. Détails ci-après : http://fosdem2013.pgconf.eu/

Le PUG de New-York est heureux d'annoncer que les inscriptions pour le PGDay NYC 2013 du vendredi 22 mars à l'hôtel ACE sont à présent ouvertes. Des tickets en pré-pré-vente sont disponibles jusqu'au 29 décembre ou jusqu'à épuisement avant date. Les achats sont possibles depuis la page suivante : http://pgday.nycpug.org/registration/

PyPgDay aura lieu le 13 mars au Santa Clara Convention Center, le premier jour de la PyCon. Informations par là : http://wiki.postgresql.org/wiki/PyPgDay2013 Vous pouvez soumettre vos propositions sur cette page jusqu'au 20 janvier 2013 : http://tinyurl.com/PyPgDayCfP

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en décembre

PostgreSQL Local

  • La conférence PGDay du FOSDEM sera tenue juste avant l'ouverture du meeting, le 1er février à Bruxelles, Belgique. Les appels à conférenciers, pour cette conférence et pour le cursus PostgreSQL du FOSDEM, sont lancés : http://fosdem2013.pgconf.eu/callforpapers/
  • Il y aura un PgDay lors de la PyCon du 13 mars 2013, au pôle de conventions de Santa Clara. D'avantage de détails quand les choses commenceront à s'organiser. N'hésitez pas à réserver la date.
  • Le PGDay 2013 de New-York City aura lieu le 22 mars. La date limite de candidature des conférenciers est fixée au 7 janvier 2013, midi (heure de New-York). Envois à l'adresse papers AT nycpug DOT org : http://pgday.nycpug.org/speakers
  • La PostgreSQL Session est programmée pour le 28 mars 2013 à Paris. L'appel à conférenciers est lancé : http://www.postgresql-sessions.org/en/5/
  • PGCon 2013 aura lieu les 23 & 24 mai 2013 à l'Université d'Ottawa. L'appel à conférenciers est lancé : http://www.pgcon.org/2013/

PostgreSQL dans les média

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

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

(lien vers l'article original)

Correctifs appliqués

Tom Lane a poussé :

  • Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code. http://git.postgresql.org/pg/commitdiff/6919b7e3294702adc39effd16634b2715d04f012
  • Ignore libedit/libreadline while probing for standard functions. Some versions of libedit expose bogus definitions of setproctitle(), optreset, and perhaps other symbols that we don't want configure to pick up on. There was a previous report of similar problems with strlcpy(), which we addressed in commit 59cf88da91bc88978b05275ebd94ac2d980c4047, but the problem has evidently grown in scope since then. In hopes of not having to deal with it again in future, rearrange configure's tests for supplied functions so that we ignore libedit/libreadline except when probing specifically for functions we expect them to provide. Per report from Christoph Berg, though this is slightly more aggressive than his proposed patch. http://git.postgresql.org/pg/commitdiff/2666a6d0b934b19d4a691b93a64c7d3208acad43
  • Fix pg_extension_config_dump() to handle update cases more sanely. If pg_extension_config_dump() is executed again for a table already listed in the extension's extconfig, the code was blindly making a new array entry. This does not seem useful. Fix it to replace the existing array entry instead, so that it's possible for extension update scripts to alter the filter conditions for configuration tables. In addition, teach ALTER EXTENSION DROP TABLE to check for an extconfig entry for the target table, and remove it if present. This is not a 100% solution because it's allowed for an extension update script to just summarily DROP a member table, and that code path doesn't go through ExecAlterExtensionContentsStmt. We could probably make that case clean things up if we had to, but it would involve sticking a very ugly wart somewhere in the guts of dependency.c. Since on the whole it seems quite unlikely that extension updates would want to remove pre-existing configuration tables, making the case possible with an explicit command seems sufficient. Per bug #7756 from Regina Obe. Back-patch to 9.1 where extensions were introduced. http://git.postgresql.org/pg/commitdiff/343c2a865bc6c0a03358709df854ce1eac52ca45
  • Fix documentation typo. "GetForeignTableColumnOptions" should be "GetForeignColumnOptions". Noted by Metin Döşlü. http://git.postgresql.org/pg/commitdiff/eb035068121532ed7db47081e71655746d31cd16
  • Prevent failure when RowExpr or XmlExpr is parse-analyzed twice. transformExpr() is required to cope with already-transformed expression trees, for various ugly-but-not-quite-worth-cleaning-up reasons. However, some of its newer subroutines hadn't gotten the memo. This accounts for bug #7763 from Norbert Buchmuller: transformRowExpr() was overwriting the previously determined type of a RowExpr during CREATE TABLE LIKE INCLUDING INDEXES. Additional investigation showed that transformXmlExpr had the same kind of problem, but all the other cases seem to be safe. Andres Freund and Tom Lane http://git.postgresql.org/pg/commitdiff/31bc839724439440b2e94ea616b28ce5be94e19c

Peter Eisentraut a poussé :

Andrew Dunstan a poussé :

Heikki Linnakangas a poussé :

  • Check if we've reached end-of-backup point also if no redo is required. If you restored from a backup taken from a standby, and the last record in the backup is the checkpoint record, ie. there is no redo required except for the checkpoint record, we would fail to notice that we've reached the end-of-backup point, and the database is consistent. The result was an error "WAL ends before end of online backup". To fix, move the have-we-reached-end-of-backup check into CheckRecoveryConsistency(), which is already responsible for similar checks with minRecoveryPoint, and is called in the right places. Backpatch to 9.2, this check and bug did not exist before that. http://git.postgresql.org/pg/commitdiff/e43f947bf32f3ea4caa5b895ca7c7659b17192ae
  • Don't set ThisTimeLineID in checkpointer & bgwriter during recovery. We used to set it to the current recovery target timeline, but the recovery target timeline can change during recovery, leaving ThisTimeLineID at an old value. That seems worse than always leaving it at zero to begin with. AFAICS there was no good reason to set it in the first place. ThisTimeLineID is not needed in checkpointer or bgwriter process, until it's time to write the end-of-recovery checkpoint, and at that point ThisTimeLineID is updated anyway. http://git.postgresql.org/pg/commitdiff/1a11d4609efaae39d9b7472fb965bca1c0aeda01
  • Fix recycling of WAL segments after switching timeline during recovery. This was broken before, we would recycle old WAL segments on wrong timeline after the recovery target timeline had changed, but my recent commit to not initialize ThisTimeLineID at all in a standby's checkpointer process broke this completely. The problem is that when installing a recycled WAL segment as a future one, ThisTimeLineID is used to construct the filename. To fix, always update ThisTimeLineID to the current timeline being recovered, before recycling WAL segments at a restartpoint. This still leaves a small window where we might install WAL segments under wrong timeline ID, if the timeline is changed just as we're about to start recycling. Also, even if we're replaying timeline X at the momnent, there's no guarantee that we'll need as many WAL segments on that timeline as we recycle. We might be just about to reach the point where we switch to next timeline, so might only need one more WAL segment on the current timeline. We'll live with the waste in that situation. Bug pointed out by Fujii Masao. 9.1 and 9.2 had the same issue, when recovery target timeline was changed, but I committed a slightly different version of this patch on those branches. http://git.postgresql.org/pg/commitdiff/343ee00b730e9c422082160718b9785f0cb7f8f6
  • Follow TLI of last replayed record, not recovery target TLI, in walsenders. Most of the time, the last replayed record comes from the recovery target timeline, but there is a corner case where it makes a difference. When the startup process scans for a new timeline, and decides to change recovery target timeline, there is a window where the recovery target TLI has already been bumped, but there are no WAL segments from the new timeline in pg_xlog yet. For example, if we have just replayed up to point 0/30002D8, on timeline 1, there is a WAL file called 000000010000000000000003 in pg_xlog that contains the WAL up to that point. When recovery switches recovery target timeline to 2, a walsender can immediately try to read WAL from 0/30002D8, from timeline 2, so it will try to open WAL file 000000020000000000000003. However, that doesn't exist yet - the startup process hasn't copied that file from the archive yet nor has the walreceiver streamed it yet, so walsender fails with error "requested WAL segment 000000020000000000000003 has already been removed". That's harmless, in that the standby will try to reconnect later and by that time the segment is already created, but error messages that should be ignored are not good. To fix that, have walsender track the TLI of the last replayed record, instead of the recovery target timeline. That way walsender will not try to read anything from timeline 2, until the WAL segment has been created and at least one record has been replayed from it. The recovery target timeline is now xlog.c's internal affair, it doesn't need to be exposed in shared memory anymore. This fixes the error reported by Thom Brown. depesz the same error message, but I'm not sure if this fixes his scenario. http://git.postgresql.org/pg/commitdiff/af275a12dfeecd621ed9899a9382f26a68310263
  • Forgot to remove extern declaration of GetRecoveryTargetTLI(). Fujii Masao http://git.postgresql.org/pg/commitdiff/d57a97343ecec89ecb7d932c21c886058ad64e6b
  • Fix race condition if a file is removed while pg_basebackup is running. If a relation file was removed when the server-side counterpart of pg_basebackup was just about to open it to send it to the client, you'd get a "could not open file" error. Fix that. Backpatch to 9.1, this goes back to when pg_basebackup was introduced. http://git.postgresql.org/pg/commitdiff/36e4456d78b6a27cdaf82280b98998fc3bf3e9c7
  • Fix sloppiness in the timeline switch over streaming replication patch. Here's another attempt at fixing the logic that decides how far the WAL can be streamed, which was still broken if the timeline changed while streaming. You would get an assertion failure. The way the logic is now written is more readable, too. Thom Brown reported the assertion failure. http://git.postgresql.org/pg/commitdiff/1ff92eea140ccf0503b7399549031976e5c6642e

Bruce Momjian 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 a patch to implement SP-GiST for ranges based on 2d-mapping and quad-tree.
  • Alexander Korotkov sent in another revision of a patch to implement index support for DFA regexes.
  • Andres Freund sent in a patch to rearrange how XLByte* is used.
  • Shigeru HANADA and Pavel Stehule traded patches to add \pset to psql.
  • Amit Kapila sent in another revision of a patch to add hooks for pre- and post-processor executables for COPY and \copy.
  • KaiGai Kohei sent in another revision of a patch to add row-level access control.
  • Laurenz Albe sent in a patch to fix a bug in the LDAP documentation.
  • Tomas Vondra sent in another revision of a patch to enable reducing the amount of pgbench output.
  • Andres Freund sent in a patch to removes some of the cruft from gram.y.
  • Gurjeet Singh sent in another revision of a patch to use 64-bit ints in pgbench for performance.
  • Peter Eisentraut sent in a patch to improve PL/Python on OS X.
  • Peter Geoghegan sent in another revision of a patch to improve memory usage in tuplesort.
  • Marko (johto) Tiikkaja sent in a patch to add a STRICT option to PERFORM in PL/pgsql.
  • Phil Sorber sent in two more revisions of a patch to create a pg_ping utility.
  • Marko Kreen sent in a patch to fix an infelicity in pgcrypto when SSL is on.
  • Bruce Momjian sent in a patch to speed up pg_upgrade.
  • KaiGai Kohei sent in another revision of a patch to add write support to the FDW interface.
  • Tomas Vondra sent in another revision of a patch to optimize droppign multiple tables in a transaction.