PostgreSQL La base de donnees la plus sophistiquee au monde.

Twitter


Utilisateur




Langue

Traductions de cette page:




Nouvelles hebdomadaires de PostgreSQL - 24 avril 2011

Nouveau sondage : avez-vous utilisé pg_upgrade ? http://www.postgresql.org/community

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en avril

PostgreSQL Local

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Robert Haas a poussé :

Andrew Dunstan a poussé :

Tom Lane a poussé :

  • Improve findoidjoins to cover more cases. Teach the program and script to deal with OID-array referencing columns, which we now have several of. Also, modify the recommended usage process to specify that the program should be run against the regression database rather than template1. This lets it find numerous joins that cannot be found in template1 because the relevant catalogs are entirely empty. Together these changes add seventeen formerly-missed cases to the oidjoins regression test. http://git.postgresql.org/pg/commitdiff/795c382e8caf27f9db2fb09d12384b8183280fee
  • Improve cost estimation for aggregates and window functions. The previous coding failed to account properly for the costs of evaluating the input expressions of aggregates and window functions, as seen in a recent gripe from Claudio Freire. (I said at the time that it wasn't counting these costs at all; but on closer inspection, it was effectively charging these costs once per output tuple. That is completely wrong for aggregates, and not exactly right for window functions either.) There was also a hard-wired assumption that aggregates and window functions had procost 1.0, which is now fixed to respect the actual cataloged costs. The costing of WindowAgg is still pretty bogus, since it doesn't try to estimate the effects of spilling data to disk, but that seems like a separate issue. http://git.postgresql.org/pg/commitdiff/e6a30a8c3c81a7a2949f852379d34a19dfc26a0d
  • - Update oidjoins regression test for 9.1 catalog schema additions. http://git.postgresql.org/pg/commitdiff/970d8a39736fd67e3ebf406ed8129eed0767d15d
  • Fix handling of collations in multi-row VALUES constructs. Per spec we ought to apply select_common_collation() across the expressions in each column of the VALUES table. The original coding was just taking the first row and assuming it was representative. This patch adds a field to struct RangeTblEntry to carry the resolved collations, so initdb is forced for changes in stored rule representation. http://git.postgresql.org/pg/commitdiff/918854cc08868d569aad3bdf2529fc61c66ecde5
  • Refrain from canonicalizing a client_encoding setting of "UNICODE". While "UTF8" is the correct name for this encoding, existing JDBC drivers expect that if they send "UNICODE" it will read back the same way; they fail with an opaque "Protocol error" complaint if not. This will be fixed in the 9.1 drivers, but until older drivers are no longer in use in the wild, we'd better leave "UNICODE" alone. Continue to canonicalize all other inputs. Per report from Steve Singer and subsequent discussion. http://git.postgresql.org/pg/commitdiff/390cf3209b718382c0ec9793b714422189e9b68b
  • Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself." This reverts commit 4b6106ccfea21e86943f881edcf3cfc03661a415 of 2011-04-15. There's a better way to do it, which will follow shortly. http://git.postgresql.org/pg/commitdiff/c096d19b74a637443109e528000342e896b150f3
  • Avoid changing an index's indcheckxmin horizon during REINDEX. There can never be a need to push the indcheckxmin horizon forward, since any HOT chains that are actually broken with respect to the index must pre-date its original creation. So we can just avoid changing pg_index altogether during a REINDEX operation. This offers a cleaner solution than my previous patch for the problem found a few days ago that we mustn't try to update pg_index while we are reindexing it. System catalog indexes will always be created with indcheckxmin = false during initdb, and with this modified code we should never try to change their pg_index entries. This avoids special-casing system catalogs as the former patch did, and should provide a performance benefit for many cases where REINDEX formerly caused an index to be considered unusable for a short time. Back-patch to 8.3 to cover all versions containing HOT. Note that this patch changes the API for index_build(), but I believe it is unlikely that any add-on code is calling that directly. http://git.postgresql.org/pg/commitdiff/8c19977e9c515cc29af449a7ab6c25e496f539f3
  • Make plan_cluster_use_sort cope with no IndexOptInfo for the target index. The original coding assumed that such a case represents caller error, but actually get_relation_info will omit generating an IndexOptInfo for any index it thinks is unsafe to use. Therefore, handle this case by returning "true" to indicate that a seqscan-and-sort is the preferred way to implement the CLUSTER operation. New bug in 9.1, no backpatch needed. Per bug #5985 from Daniel Grace. http://git.postgresql.org/pg/commitdiff/5b8e442953da0bf4950b86c7cb4a6117842aedf7
  • Set indcheckxmin true when REINDEX fixes an invalid or not-ready index. Per comment from Greg Stark, it's less clear that HOT chains don't conflict with the index than it would be for a valid index. So, let's preserve the former behavior that indcheckxmin does get set when there are potentially-broken HOT chains in this case. This change does not cause any pg_index update that wouldn't have happened anyway, so we're not re-introducing the previous bug with pg_index updates, and surely the case is not significant from a performance standpoint; so let's be as conservative as possible. http://git.postgresql.org/pg/commitdiff/9ad7e15507ffa14f51d80d6ae3ed942ea191826d
  • Fix bugs in indexing of in-doubt HOT-updated tuples. If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know whether to index it or not except by waiting to see if the deleting transaction commits. If it doesn't, the tuple might again be LIVE, meaning we have to index it. So wait and recheck in that case. Also, we must not rely on ii_BrokenHotChain to decide that it's possible to omit tuples from the index. That could result in omitting tuples that we need, particularly in view of yesterday's fixes to not necessarily set indcheckxmin (but it's broken even without that, as per my analysis today). Since this is just an extremely marginal performance optimization, dropping the test shouldn't hurt. These cases are only expected to happen in system catalogs (they're possible there due to early release of RowExclusiveLock in most catalog-update code paths). Since reindexing of a system catalog isn't a particularly performance-critical operation anyway, there's no real need to be concerned about possible performance degradation from these changes. The worst aspects of this bug were introduced in 9.0 --- 8.x will always wait out a DELETE_IN_PROGRESS tuple. But I think dropping index entries on the strength of ii_BrokenHotChain is dangerous even without that, so back-patch removal of that optimization to 8.3 and 8.4. http://git.postgresql.org/pg/commitdiff/520bcd9c9bb4d06627054e1c567bac1feb2da879
  • Avoid possible divide-by-zero in gincostestimate. Per report from Jeff Janes. http://git.postgresql.org/pg/commitdiff/92647fc4b9cd7406afb2ee240a20082ba6097177
  • Make a code-cleanup pass over the collations patch. This patch is almost entirely cosmetic --- mostly cleaning up a lot of neglected comments, and fixing code layout problems in places where the patch made lines too long and then pgindent did weird things with that. I did find a bug-of-omission in equalTupleDescs(). http://git.postgresql.org/pg/commitdiff/9e9b9ac7d1860fbb98eb4db17a94ff25524b6447
  • De-kludge contrib/btree_gin for collations. Using DEFAULT_COLLATION_OID in the comparePartial functions was not only a lame hack, but outright wrong, because the compare functions for collation-aware types were already responding to the declared index collation. So comparePartial would have the wrong expectation about the index's sort order, possibly leading to missing matches for prefix searches. http://git.postgresql.org/pg/commitdiff/474ff212e5c2e89a9955cc2355cb96b2fe40398e
  • Make GIN and GIST pass the index collation to all their support functions. Experimentation with contrib/btree_gist shows that the majority of the GIST support functions potentially need collation information. Safest policy seems to be to pass it to all of them, instead of making assumptions about which ones could possibly need it. http://git.postgresql.org/pg/commitdiff/ae20bf1740c53494e15fadfd8c2c6444032a3441
  • Fix contrib/btree_gist to handle collations properly. Make use of the collation attached to the index column, instead of hard-wiring DEFAULT_COLLATION_OID. (Note: in theory this could require reindexing btree_gist indexes on textual columns, but I rather doubt anyone has one with a non-default declared collation as yet.) http://git.postgresql.org/pg/commitdiff/bb850306307d3d6ebb611c4039ae127236eb1699
  • Fix char2wchar/wchar2char to support collations properly. These functions should take a pg_locale_t, not a collation OID, and should call mbstowcs_l/wcstombs_l where available. Where those functions are not available, temporarily select the correct locale with uselocale(). This change removes the bogus assumption that all locales selectable in a given database have the same wide-character conversion method; in particular, the collate.linux.utf8 regression test now passes with LC_CTYPE=C, so long as the database encoding is UTF8. I decided to move the char2wchar/wchar2char functions out of mbutils.c and into pg_locale.c, because they work on wchar_t not pg_wchar_t and thus don't really belong with the mbutils.c functions. Keeping them where they were would have required importing pg_locale_t into pg_wchar.h somehow, which did not seem like a good plan. http://git.postgresql.org/pg/commitdiff/2ab0796d7a3a7116a79b65531fd33f1548514b52
  • Adjust comments about collate.linux.utf8 regression test. This test should now work in any database with UTF8 encoding, regardless of the database's default locale. The former restriction was really "doesn't work if default locale is C", and that was because of not handling mbstowcs/wcstombs correctly. http://git.postgresql.org/pg/commitdiff/1abd146dddc1dc5efff5ccac065c460108acbaa9
  • Hash indexes had better pass the index collation to support functions, too. Per experimentation with contrib/citext, whose hash function assumes that it'll be passed a collation. http://git.postgresql.org/pg/commitdiff/a0b75a41a907e1582acdb8aa6ebb9cacca39d7d8

Heikki Linnakangas a poussé :

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Shigeru HANADA sent in another revision of the patch to fix foreign table privileges.
  • Robert Haas sent in a patch for 9.2 to allow for time-delayed standbys.
  • Noah Misch sent in another revision of the patch to resolve an incompatibility between pg_dump --binary-upgrade and ALTER TYPE ... DROP ATTRIBUTE.
  • Bruce Momjian sent in three revisions of a patch to make pg_upgrade disable autovacuum.
  • Dan Ports sent in a patch to fix the UPDATE performance under SSI.
  • Leonardo Francalanci sent in a patch to allow switching tables from UNLOGGED to LOGGED state.
  • Alex Hunsaker sent in two revisions of a patch to enable the new perl 5.14 to work with the build system.
  • Gianni Ciolli sent in a patch to fix a performance issue in NOTIFY.
  • Andrew Dunstan sent in a patch to do a consolidate cleanup on win32.
  • Peter Eisentraut sent in a patch to allow make check to work in contrib.

 
pgwn/24_avril_2011.txt · Dernière modification: 2011/04/26 23:44 par buggy