Nouvelles hebdomadaires de PostgreSQL - 28 août 2011
PostgreSQL 9.1 RC1 est disponible. Tests !
http://www.postgresql.org/about/news.1341
[ndt: traduction française de l'annonce :
http://blog.postgresql.fr/index.php?post/2011/08/24/Sortie-de-PostgreSQL-9.1-RC-1]
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en août
PostgreSQL Local
- Postgres Open 2011, conférence ayant pour thème les évolutions brutales dans l'industrie de la base de données, aura lieu du 14 au 16 septembre 2011 à Chicago (Illinois, États-Unis) à l'hôtel "Westin Michigan Avenue" :
http://postgresopen.org
- Le PG-Day Denver 2011 aura lieu le samedi 17 septembre 2011 dans le campus Auraria près de Denver, Colorado :
http://pgday.consistentstate.com/
- 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/
- 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/
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 trigger WHEN conditions when both BEFORE and AFTER triggers exist. Due to tuple-slot mismanagement, evaluation of WHEN conditions for AFTER ROW UPDATE triggers could crash if there had been a BEFORE ROW trigger fired for the same update. Fix by not trying to overload the use of estate->es_trig_tuple_slot. Per report from Yoran Heling. Back-patch to 9.0, when trigger WHEN conditions were introduced.
http://git.postgresql.org/pg/commitdiff/b33f78df17c32364d51f6e5128f8d81d7d3013a2
- Fix handling of extension membership when filling in a shell operator. The previous coding would result in deleting and not re-creating the extension membership pg_depend rows, since there was no CommandCounterIncrement that would allow recordDependencyOnCurrentExtension to see that the deletion had happened. Make it work like the shell type case, ie, keep the existing entries (and then throw an error if they're for the wrong extension). Per bug #6172 from Hitoshi Harada. Investigation and fix by Dimitri Fontaine.
http://git.postgresql.org/pg/commitdiff/660a081c3f6892dae353136fa0883cd3c69813d4
- Fix overoptimistic assumptions in column width estimation for subqueries. set_append_rel_pathlist supposed that, while computing per-column width estimates for the appendrel, it could ignore child rels for which the translated reltargetlist entry wasn't a Var. This gave rise to completely silly estimates in some common cases, such as constant outputs from some or all of the arms of a UNION ALL. Instead, fall back on get_typavgwidth to estimate from the value's datatype; which might be a poor estimate but at least it's not completely wacko. That problem was exposed by an Assert in set_subquery_size_estimates, which unfortunately was still overoptimistic even with that fix, since we don't compute attr_widths estimates for appendrels that are entirely excluded by constraints. So remove the Assert; we'll just fall back on get_typavgwidth in such cases. Also, since set_subquery_size_estimates calls set_baserel_size_estimates which calls set_rel_width, there's no need for set_subquery_size_estimates to call get_typavgwidth; set_rel_width will handle it for us if we just leave the estimate set to zero. Remove the unnecessary code. Per report from Erik Rijkers and subsequent investigation.
http://git.postgresql.org/pg/commitdiff/43f0c20839aa82705700e4de5bb452b7f044c838
- Make CREATE EXTENSION check schema creation permissions. When creating a new schema for a non-relocatable extension, we neglected to check whether the calling user has permission to create schemas. That didn't matter in the original coding, since we had already checked superuserness, but in the new dispensation where users need not be superusers, we should check it. Use CreateSchemaCommand() rather than calling NamespaceCreate() directly, so that we also enforce the rules about reserved schema names. Per complaint from KaiGai Kohei, though this isn't the same as his patch.
http://git.postgresql.org/pg/commitdiff/d4aa491493e6cfa7542d16deba4018c2fd7af9fd
- Fix multiple bugs in extension dropping. When we implemented extensions, we made findDependentObjects() treat EXTENSION dependency links similarly to INTERNAL links. However, that logic contained an implicit assumption that an object could have at most one INTERNAL dependency, so it did not work correctly for objects having both INTERNAL and DEPENDENCY links. This led to failure to drop some extension member objects when dropping the extension. Furthermore, we'd never actually exercised the case of recursing to an internally-referenced (owning) object from anything other than a NORMAL dependency, and it turns out that passing the incoming dependency's flags to the owning object is the Wrong Thing. This led to sometimes dropping a whole extension silently when we should have rejected the drop command for lack of CASCADE. Since we obviously were under-testing extension drop scenarios, add some regression test cases. Unfortunately, such test cases require some extensions (duh), so we can't test for problems in the core regression tests. I chose to add them to the earthdistance contrib module, which is a good test case because it has a dependency on the cube contrib module. Back-patch to 9.1. Arguably these are pre-existing bugs in INTERNAL dependency handling, but since it appears that the cases can never arise pre-9.1, I'll refrain from back-patching the logic changes further than that.
http://git.postgresql.org/pg/commitdiff/cb5c2ba2d82688d29b5902d86b993a54355cad4d
- Avoid locale dependency in expected output. We'll have to settle for just listing the extensions' data types, since function arguments seem to sort differently in different locales. Per buildfarm results.
http://git.postgresql.org/pg/commitdiff/ba69b419a8015986d018e25173f8cf4233a3c2d9
- Fix pgxs.mk to always add --dbname=$(CONTRIB_TESTDB) to REGRESS_OPTS. The previous coding resulted in contrib modules unintentionally overriding the use of CONTRIB_TESTDB. There seems no particularly good reason to allow that (after all, the makefile can set CONTRIB_TESTDB if that's really what it intends). In passing, document REGRESS_OPTS where the other pgxs.mk options are documented. Back-patch to 9.1 --- in prior versions, there were no cases of contrib modules setting REGRESS_OPTS without including the --dbname switch, so while the coding was fragile there was no actual bug.
http://git.postgresql.org/pg/commitdiff/d1d388603e4f9233d3e01847405b239972a54fdf
- Fix pgstatindex() to give consistent results for empty indexes. For an empty index, the pgstatindex() function would compute 0.0/0.0 for its avg_leaf_density and leaf_fragmentation outputs. On machines that follow the IEEE float arithmetic standard with any care, that results in a NaN. However, per report from Rushabh Lathia, Microsoft couldn't manage to get this right, so you'd get a bizarre error on Windows. Fix by forcing the results to be NaN explicitly, rather than relying on the division operator to give that or the snprintf function to print it correctly. I have some doubts that this is really the most useful definition, but it seems better to remain backward-compatible with those platforms for which the behavior wasn't completely broken. Back-patch to 8.2, since the code is like that in all current releases.
http://git.postgresql.org/pg/commitdiff/af7d181298fbcd4eb225ee349598edd4611c652d
- Add a regression test for pgstattuple. This is mainly to prove that the NaN fix actually works cross-platform.
http://git.postgresql.org/pg/commitdiff/bd165757f4e0914efb808927482c46f719adcbc5
- Add "%option warn" to all flex input files that lacked it. This is recommended in the flex manual, and there seems no good reason not to use it everywhere.
http://git.postgresql.org/pg/commitdiff/2e95f1f002bc3f0504dffa6d9ffed0dc914ecec1
- Fix psql lexer to avoid use of backtracking. Per previous experimentation, backtracking slows down lexing performance significantly (by about a third). It's usually pretty easy to avoid, just need to have rules that accept an incomplete construct and do whatever the lexer would have done otherwise. The backtracking was introduced by the patch that added quoted variable substitution. Back-patch to 9.0 where that was added.
http://git.postgresql.org/pg/commitdiff/77ce50a40364a3605f775d3f0efca2e1caa70291
- Add makefile rules to check for backtracking in backend and psql lexers. Per discussion, we should enforce the policy of "no backtracking" in these performance-sensitive scanners.
http://git.postgresql.org/pg/commitdiff/ecf248737a4c0705bf7d79fdd52b5271618f7103
- Support non-ASCII letters in psql variable names. As in the backend, the implementation actually accepts any non-ASCII character, but we only document that you can use letters.
http://git.postgresql.org/pg/commitdiff/e86fdb0ab224eaa73d907ab16a2dd0e0058699e0
- Clean up weird corner cases in lexing of psql meta-command arguments. These changes allow backtick command evaluation and psql variable interpolation to happen on substrings of a single meta-command argument. Formerly, no such evaluations happened at all if the backtick or colon wasn't the first character of the argument, and we considered an argument completed as soon as we'd processed one backtick, variable reference, or quoted substring. A string like 'FOO'BAR was thus taken as two arguments not one, not exactly what one would expect. In the new coding, an argument is considered terminated only by unquoted whitespace or backslash. Also, clean up a bunch of omissions, infelicities and outright errors in the psql documentation of variables and metacommand argument syntax.
http://git.postgresql.org/pg/commitdiff/928311a463d480ca566e2905a369ac6aa0c3e210
- Fix potential memory clobber in tsvector_concat(). tsvector_concat() allocated its result workspace using the "conservative" estimate of the sum of the two input tsvectors' sizes. Unfortunately that wasn't so conservative as all that, because it supposed that the number of pad bytes required could not grow. Which it can, as per test case from Jesper Krogh, if there's a mix of lexemes with positions and lexemes without them in the input data. The fix is to assume that we might add a not-previously-present pad byte for each and every lexeme in the two inputs; which really is conservative, but it doesn't seem worthwhile to try to be more precise. This is an aboriginal bug in tsvector_concat, so back-patch to all versions containing it.
http://git.postgresql.org/pg/commitdiff/00eb036c111b8f72a34ca729efccd785761d977e
- Improve comments describing tsvector data structure.
http://git.postgresql.org/pg/commitdiff/40271811cb9c4906041afc21a3b2c2f31f534fd8
- Ensure we discard unread/unsent data when abandoning a connection attempt. There are assorted situations wherein PQconnectPoll() will abandon a connection attempt and try again with different parameters (eg, SSL versus not SSL). However, the code forgot to discard any pending data in libpq's I/O buffers when doing this. In at least one case (server returns E message during SSL negotiation), there is unread input data which bollixes the next connection attempt. I have not checked to see whether this is possible in the other cases where we close the socket and retry, but it seems like a matter of good defensive programming to add explicit buffer-flushing code to all of them. This is one of several issues exposed by Daniel Farina's report of misbehavior after a server-side fork failure. This has been wrong since forever, so back-patch to all supported branches.
http://git.postgresql.org/pg/commitdiff/724e30c9f886efd852f714d47c56336ffa6916ec
- Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
http://git.postgresql.org/pg/commitdiff/a49fbaaf8d461ff91912c30b3563d54649474c80
- Include $cc_string in the info reported by a configure run. Without this, it's not very easy to tell which compiler version a buildfarm animal is actually using at the moment.
http://git.postgresql.org/pg/commitdiff/2c5d6f1fb570db1a287532d3291d284710e756bf
- Be more user-friendly about unsupported cases for parallel pg_restore. If we are unable to do a parallel restore because the input file is stdin or is otherwise unseekable, we should complain and fail immediately, not after having done some of the restore. Complaining once per thread isn't so cool either, and the messages should be worded to make it clear this is an unsupported case not some weird race-condition bug. Per complaint from Lonni Friedman. Back-patch to 8.4, where parallel restore was introduced.
http://git.postgresql.org/pg/commitdiff/d6e7abe45a64378113c1c717a831b7aac9c451df
- Actually, all of parallel restore's limitations should be tested earlier. On closer inspection, whining in restore_toc_entries_parallel is really much too late for any user-facing error case. The right place to do it is at the start of RestoreArchive(), before we've done anything interesting (such as trying to DROP all the targets ...) Back-patch to 8.4, where parallel restore was introduced.
http://git.postgresql.org/pg/commitdiff/6e1f1fee97839599cf59f37f7051786a09f3b240
Bruce Momjian a poussé :
Robert Haas a poussé :
Heikki Linnakangas a poussé :
Peter Eisentraut a poussé :
Alvaro Herrera a poussé :
Andrew Dunstan a poussé :
Correctifs rejetés (à ce jour)
- Pas de déception cette semaine :-)
Correctifs en attente
- Pavan Deolasse sent in another revisions of the patch to track the vacuum generation number in the line pointer itself.
- Alexander Korotkov and Heikki Linnakangas traded patches to speed up GiST index builds.
- David Gould and Robert Haas traded patches to diagnose and fix an issue with locking.
- Pavel Stehule sent in a patch for PL/pgsql to plan SQL statements early.
- Sushant Sinha sent in a patch to limit the number of words generated in a headline in text search.
- Jeff Davis sent in another revision of the patch to implement range types.
- Steve Singer sent in a patch to allow skipping WAL on COPY.
- Andrew Dunstan sent in a patch to implement a --no-table-date option for pg_dump. This is useful when only some tables' data is relevant to a dump.
- Andrew Dunstan sent in patches to allow pg_dump and pg_restore to omit or use exclusively post-data items.
- Dougal Sutherland sent in a patch to clarify postgresql.conf.sample.
- KaiGai Kohei sent in another revision of the patch intended to fix some leaks in views.
- Tomas Vondra sent in a patch to enable regular logging of checkpoint progress.
- KaiGai Kohei sent in another revision of the patch to allow access to the userspace access vector cache.
- Bruce Momjian sent in a patch intended to remove redundant #include references.
- Dean Rasheed sent in two patches intended to allow relative timestamps as input, e.g. 'tomorrow 10:30'. 'Christmas plus three fortnights' will need to wait for a later patch.
- Greg Smith sent in two more revisions of a patch to allow finer-grained tracking of vacuums.
- YAMAMOTO Takashi sent in a patch to remove tab characters from a README.
- KaiGai Kohei sent in a patch to enable object access hooks with arguments.