PostgreSQL La base de donnees la plus sophistiquee au monde.

Twitter


Utilisateur




Langue

Traductions de cette page:




Nouvelles hebdomadaires de PostgreSQL - 13 mars 2011

Publication de PostgreSQL 9.1alpha4, avec moultes, grosses gâteries ! Il s'agit de la dernière alpha planifiée pour la 9.1. Elle est disponible par là : http://www.postgresql.org/developer/alpha

Nouveau sondage : quelle est la fonctionnalité de la 9.1 qui vous intéresse le plus ? http://www.postgresql.org/community

Offres d'emplois autour de PostgreSQL en mars

PostgreSQL Local

PostgreSQL dans les média

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

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

(lien vers l'article original)

Revues de code

Correctifs appliqués

Heikki Linnakangas a poussé :

  • Silence compiler warning about undefined function when compiling without assertions. http://git.postgresql.org/pg/commitdiff/baabf05196922164db80bdc45fd0660c8700f1f7
  • Begin error message with lower-case letter. http://git.postgresql.org/pg/commitdiff/97e3dacd84f185bff86485f54c665621222c576b
  • Document the DEFERRABLE option in SET TRANSACTION command. Kevin Grittner http://git.postgresql.org/pg/commitdiff/faba108fe4f2491ebc2b7faf4343f952125cc661
  • If recovery_target_timeline is set to 'latest' and standby mode is enabled, periodically rescan the archive for new timelines, while waiting for new WAL segments to arrive. This allows you to set up a standby server that follows the TLI change if another standby server is promoted to master. Before this, you had to restart the standby server to make it notice the new timeline. This patch only scans the archive for TLI changes, it won't follow a TLI change in streaming replication. That is much needed too, but it would be a much bigger patch than I dare to sneak in this late in the release cycle. There was discussion on improving the sanity checking of the WAL segments so that the system would notice more reliably if the new timeline isn't an ancestor of the current one, but that is not included in this patch. Reviewed by Fujii Masao. http://git.postgresql.org/pg/commitdiff/1a4ab9ec23f0635a4c15b069df60b545814650e9
  • Truncate predicate lock manager's SLRU lazily at checkpoint. That's safer than doing it aggressively whenever the tail-XID pointer is advanced, because this way we don't need to do it while holding SerializableXactHashLock. This also fixes bug #5915 spotted by YAMAMOTO Takashi, and removes an obsolete comment spotted by Kevin Grittner. http://git.postgresql.org/pg/commitdiff/4cd3fb6e1244383fc9f77906e7162de0559ba354
  • Don't throw a warning if vacuum sees PD_ALL_VISIBLE flag set on a page that contains newly-inserted tuples that according to our OldestXmin are not yet visible to everyone. The value returned by GetOldestXmin() is conservative, and it can move backwards on repeated calls, so if we see that contradiction between the PD_ALL_VISIBLE flag and status of tuples on the page, we have to assume it's because an earlier vacuum calculated a higher OldestXmin value, and all the tuples really are visible to everyone. We have received several reports of this bug, with the "PD_ALL_VISIBLE flag was incorrectly set in relation ..." warning appearing in logs. We were finally able to hunt it down with David Gould's help to run extra diagnostics in an environment where this happened frequently. Also reword the warning, per Robert Haas' suggestion, to not imply that the PD_ALL_VISIBLE flag is necessarily at fault, as it might also be a symptom of corruption on a tuple header. Backpatch to 8.4, where the PD_ALL_VISIBLE flag was introduced. http://git.postgresql.org/pg/commitdiff/93d888232e80e4d676e24fe93ae6d27459d966be
  • Fix overly strict assertion in SummarizeOldestCommittedSxact(). There's a race condition where SummarizeOldestCommittedSxact() is called even though another backend already cleared out all finished sxact entries. That's OK, RegisterSerializableTransactionInt() can just retry getting a news xact slot from the available-list when that happens. Reported by YAMAMOTO Takashi, bug #5918. http://git.postgresql.org/pg/commitdiff/46c333a9638b329a3c8076d978f27c5b05c0d5f0
  • Fix bugs in the isolation tester flex rules. Tom Lane pointed out that it was giving a warning: "-s option given but default rule can be matched". That was because there was no rule to handle newline in a quoted string. I made that throw an error. Also, line number tracking was broken, giving incorrect line number on error. Fixed that too. http://git.postgresql.org/pg/commitdiff/74a09d92101f36a5fe66f4f74253708931546e4c
  • In ecpg preprocessor, don't try to look up constants in the test for variable hiding. A constant is not a variable. It worked in most cases by accident, because we add constants to the global list of variables (why?), but float constants like 1.23 were interpreted as struct field references, and not found. Backpatch to 9.0, where the test for variable hiding was added. http://git.postgresql.org/pg/commitdiff/30e8b3e58ed56cbc07ae7cd392ee4b9782178ca5

Tom Lane a poussé :

  • Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments. http://git.postgresql.org/pg/commitdiff/7193a90fc1e3ce0be7688c1452e813bd0ddc101b
  • Minor copy-editing in CREATE TRIGGER reference page. Per suggestions from Thom Brown and Robert Haas. http://git.postgresql.org/pg/commitdiff/f8c0af840d84086249647d4415bd35903bfc7933
  • Improve description of inquiry functions that accept regclass. Per a suggestion from Thom Brown, though this is not his proposed patch. http://git.postgresql.org/pg/commitdiff/cfcdc99db67172d46a5e226375fa97e5c5a62267
  • Add missing keywords to gram.y's unreserved_keywords list. We really need an automated check for this ... and did VALIDATE really need to become a keyword at all, rather than picking some other syntax using existing keywords? http://git.postgresql.org/pg/commitdiff/3f7d24da16d32ad0fa5abf04b669e86a7d458160
  • Assorted editing for collation documentation. I made a pass over this to familiarize myself with the feature, and found some things that could be improved. http://git.postgresql.org/pg/commitdiff/a612b17120fc011cefcdec6948b1cc8543529d06
  • A bit more editing for collation documentation. http://git.postgresql.org/pg/commitdiff/c0dc44ebba0bbce430e71adb195ceec66417d40b
  • Adjust the permissions required for COMMENT ON ROLE. Formerly, any member of a role could change the role's comment, as of course could superusers; but holders of CREATEROLE privilege could not, unless they were also members. This led to the odd situation that a CREATEROLE holder could create a role but then could not comment on it. It also seems a bit dubious to let an unprivileged user change his own comment, let alone those of group roles he belongs to. So, change the rule to be "you must be superuser to comment on a superuser role, or hold CREATEROLE to comment on non-superuser roles". This is the same as the privilege check for creating/dropping roles, and thus fits much better with the rule for other object types, namely that only the owner of an object can comment on it. In passing, clean up the documentation for COMMENT a little bit. Per complaint from Owen Jacobson and subsequent discussion. http://git.postgresql.org/pg/commitdiff/49a08ca1e968860fe02fa3331cc0aba361d76e02
  • Remove collation information from TypeName, where it does not belong. The initial collations patch treated a COLLATE spec as part of a TypeName, following what can only be described as brain fade on the part of the SQL committee. It's a lot more reasonable to treat COLLATE as a syntactically separate object, so that it can be added in only the productions where it actually belongs, rather than needing to reject it in a boatload of places where it doesn't belong (something the original patch mostly failed to do). In addition this change lets us meet the spec's requirement to allow COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly behavior for constructs such as "foo::type COLLATE collation". To do this, pull collation information out of TypeName and put it in ColumnDef instead, thus reverting most of the collation-related changes in parse_type.c's API. I made one additional structural change, which was to use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd nodes. This provides enough room to get rid of the "transform" wart in AlterTableCmd too, since the ColumnDef can carry the USING expression easily enough. Also fix some other minor bugs that have crept in in the same areas, like failure to copy recently-added fields of ColumnDef in copyfuncs.c. While at it, document the formerly secret ability to specify a collation in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about what the default collation selection will be when COLLATE is omitted. BTW, the three-parameter form of format_type() should go away too, since it just contributes to the confusion in this area; but I'll do that in a separate patch. http://git.postgresql.org/pg/commitdiff/a051ef699c3ed1f89088dd6bbc2574f13d0b20eb
  • Fix some oversights in distprep and maintainer-clean targets. At least two recent commits have apparently imagined that a comment in a Makefile stating that something would be included in the distribution tarball was sufficient to make it so. They hadn't bothered to hook into the upper maintainer-clean targets either. Per bug #5923 from Charles Johnson, in which it emerged that the 9.1alpha4 tarballs are short a few files that should be there. http://git.postgresql.org/pg/commitdiff/174f65ab00bb8de0f119a6a60d562b516ba71bba
  • replication/repl_gram.h needs to be cleaned too ... http://git.postgresql.org/pg/commitdiff/f6587019ed2c2123c00c18db2d1e857a6258ff85
  • Revert addition of third argument to format_type(). Including collation in the behavior of that function promotes a world view we do not want. Moreover, it was producing the wrong behavior for pg_dump anyway: what we want is to dump a COLLATE clause on attributes whose attcollation is different from the underlying type, and likewise for domains, and the function cannot do that for us. Doing it the hard way in pg_dump is a bit more tedious but produces more correct output. In passing, fix initdb so that the initial entry in pg_collation is properly pinned. It was droppable before :-( http://git.postgresql.org/pg/commitdiff/7564654adf07ec26b83c7effc7f54f7183e04519
  • Remove duplicate indexterm to silence openjade wrning. http://git.postgresql.org/pg/commitdiff/ac435a79c88f51be6bf3eb5df618c2bac6123ae4
  • Create an explicit concept of collations that work for any encoding. Use collencoding = -1 to represent such a collation in pg_collation. We need this to make the "default" entry work sanely, and a later patch will fix the C/POSIX entries to be represented this way instead of duplicating them across all encodings. All lookup operations now search first for an entry that's database-encoding-specific, and then for the same name with collencoding = -1. Also some incidental code cleanup in collationcmds.c and pg_collation.c. http://git.postgresql.org/pg/commitdiff/e3c732a85c0f247617b2d44ea567f35731b03ea6
  • Split CollateClause into separate raw and analyzed node types. CollateClause is now used only in raw grammar output, and CollateExpr after parse analysis. This is for clarity and to avoid carrying collation names in post-analysis parse trees: that's both wasteful and possibly misleading, since the collation's name could be changed while the parsetree still exists. Also, clean up assorted infelicities and omissions in processing of the node type. http://git.postgresql.org/pg/commitdiff/8acdb8bf9cebc42cee5aa96a2d594756b44173c9
  • Put in some more safeguards against executing a division-by-zero. Add dummy returns before every potential division-by-zero in int8.c, because apparently further "improvements" in gcc's optimizer have enabled it to break functions that weren't broken before. Aurelien Jarno, via Martin Pitt http://git.postgresql.org/pg/commitdiff/72330995a52fb7a3fbdc666aebc0402cdcbc9af8
  • On further reflection, we'd better do the same in int.c. We previously heard of the same problem in int24div(), so there's not a good reason to suppose the problem is confined to cases involving int8. http://git.postgresql.org/pg/commitdiff/2a26639a5d76df7f59340cfb4313763f87815ede
  • Make all comparisons done for/with statistics use the default collation. While this will give wrong answers when estimating selectivity for a comparison operator that's using a non-default collation, the estimation error probably won't be large; and anyway the former approach created estimation errors of its own by trying to use a histogram that might have been computed with some other collation. So we'll adopt this simplified approach for now and perhaps improve it sometime in the future. This patch incorporates changes from Andres Freund to make sure that selfuncs.c passes a valid collation OID to any datatype-specific function it calls, in case that function wants collation information. Said OID will now always be DEFAULT_COLLATION_OID, but at least we won't get errors. http://git.postgresql.org/pg/commitdiff/696d1f7f064402840a60b7177a838d1452ad13e6
  • Simplify list traversal logic in add_path(). Its mechanism for recovering after deleting the current list cell was a bit klugy. Borrow the technique used in other places. http://git.postgresql.org/pg/commitdiff/a2eb9e0c08ee73208b5419f5a53a6eba55809b92

Robert Haas a poussé :

Peter Eisentraut a poussé :

Michael Meskes a poussé :

Bruce Momjian a poussé :

ITAGAKI Takahiro a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Jan Urbanski sent in another flock of patches to fix PL/PythonU.
  • Fujii Masao sent in another revision of the replication server timeout patch.
  • Thom Brown sent in two revisions of doc patches for syncrep.
  • Fujii Masao sent in four revisions of a patch to add a sample recovery.conf which illustrates the use of recovery control functions.
  • Gurjeet Singh sent in another revision of the patch to allow psql to use relative paths for includes, this time with a long option (\include_relative).
  • Noah Misch sent in a patch to add test for FOR KEY LOCK.
  • Mark Kirkwood sent in another revision of the patch to constrain backend temporary file space.
  • Kevin Grittner sent in a patch to reformat the SSI files per pgindent.
  • Bruce Momjian and Christopher Browne traded patches to make constants for magic time values.
  • Robert Haas sent in a patch to enable ALTER TABLE ... ALTER CONSTRAINT ... VALID, which makes the system check whether the constraint is true if not already enforced.
  • Noah Misch sent in a patch to fix an issue with on-the-fly index tuple deletion and hot standby.
  • Bruce Momjian sent in a patch to add a comment to the template0 database.
  • Robert Haas sent in a patch to add the new keywords 9.1 features have spawned.
  • Noah Misch sent in a patch to fix some memory-related bugs he turned up while testing an instrumented version of PostgreSQL.

 
pgwn/13_mars_2011.txt · Dernière modification: 2011/03/18 01:05 par buggy