Revues de code

Correctifs appliqués

Michael Meskes a poussé :

Andrew Dunstan a poussé :

Robert Haas a poussé :

Bruce Momjian a poussé :

Peter Eisentraut a poussé :

  • Support "make check" in contrib. Added a new option --extra-install to pg_regress to arrange installing the respective contrib directory into the temporary installation. This is currently not yet supported for Windows MSVC builds. Updated the .gitignore files for contrib modules to ignore the leftovers of a temp-install check run. Changed the exit status of "make check" in a pgxs build (which still does nothing) to 0 from 1. Added "make check" in contrib to top-level "make check-world". http://git.postgresql.org/pg/commitdiff/f8ebe3bcc5debfcf2bf588aee138944688b682c0
  • Fix binary upgrade of altered typed tables. Instead of dumping them as CREATE TABLE ... OF, dump them as normal tables with the usual special processing for dropped columns, and then attach them to the type afterward, using ALTER TABLE ... OF. This is analogous to the existing handling of inherited tables. http://git.postgresql.org/pg/commitdiff/b2ef8929ae1c1b65f4b9582409463a9a2f009706
  • Rewrite installation makefile rules without for loops. install-sh can install multiple files at once, so for loops are not necessary. This was already changed for the rest of the code some time ago, but pgxs.mk was apparently forgotten, and the obsolete coding style has now been copied to the PLs as well. This also fixes the problem that the for loops in question did not catch errors. http://git.postgresql.org/pg/commitdiff/b106195b1731ce5d68e8bb5c421f09a4aae9e96a
  • Catch errors in for loop in makefile. Add "|| exit" so that the rule aborts when a command fails. http://git.postgresql.org/pg/commitdiff/5c436a79e0f4e11f80c5878a0309ce60f79e17b1

Tom Lane a poussé :

  • Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX. The expression that tried to round the value to the nearest Tim Bunce could overflow, leading to bogus output as reported in bug #5993 from Nicola Cossu. This isn't likely to ever happen in the intended usage of the function (if it could, we'd be needing to use a wider datatype instead); but it's not hard to give the expected output, so let's do so. http://git.postgresql.org/pg/commitdiff/af0f20092c8662bf7610fab07b8a1e354abba67f
  • Remove incorrect HINT for use of ALTER FOREIGN TABLE on the wrong relkind. Per discussion, removing the hint seems better than correcting it because the adjacent analogous cases in RenameRelation don't have any hints, and nobody seems to have missed 'em. Shigeru Hanada http://git.postgresql.org/pg/commitdiff/6dab96abaa8bd6775658d26517e288f4d5f6448f
  • Complain if pg_hba.conf contains "hostssl" but SSL is disabled. Most commenters agreed that this is more friendly than silently failing to match the line during actual connection attempts. Also, this will prevent corner cases that might arise when trying to handle such a line when the SSL code isn't turned on. An example is that specifying clientcert=1 in such a line would formerly result in a completely misleading complaint that root.crt wasn't present, as seen in a recent report from Marc-Andre Laverdiere. While we could have instead fixed that specific behavior, it seems likely that we'd have a continuing stream of such bizarre behaviors if we keep on allowing hostssl lines when SSL is disabled. Back-patch to 8.4, where clientcert was introduced. Earlier versions don't have this specific issue, and the code is enough different to make this patch not applicable without more work than it seems worth. http://git.postgresql.org/pg/commitdiff/c464a0657b0cdaa7fa645d53621be10963cb7741
  • Rephrase some not-supported error messages in pg_hba.conf processing. In a couple of places we said "not supported on this platform" for cases that aren't really platform-specific, but could depend on configuration options such as --with-openssl. Use "not supported by this build" instead, as that doesn't convey the impression that you can't fix it without moving to another OS; that's also more consistent with the wording used for an identical error case in guc.c. No back-patch, as the clarity gain is small enough to not be worth burdening translators with back-branch changes. http://git.postgresql.org/pg/commitdiff/71e7083532d8f6ad0cf345c3cc534b0307e816a8
  • Fix array- and path-creating functions to ensure padding bytes are zeroes. Per recent discussion, it's important for all computed datums (not only the results of input functions) to not contain any ill-defined (uninitialized) bits. Failing to ensure that can result in equal() reporting that semantically indistinguishable Consts are not equal, which in turn leads to bizarre and undesirable planner behavior, such as in a recent example from David Johnston. We might eventually try to fix this in a general manner by allowing datatypes to define identity-testing functions, but for now the path of least resistance is to expect datatypes to force all unused bits into consistent states. Per some testing by Noah Misch, array and path functions seem to be the only ones presenting risks at the moment, so I looked through all the functions in adt/array*.c and geo_ops.c and fixed them as necessary. In the array functions, the easiest/safest fix is to allocate result arrays with palloc0 instead of palloc. Possibly in future someone will want to look into whether we can just zero the padding bytes, but that looks too complex for a back-patchable fix. In the path functions, we already had a precedent in path_in for just zeroing the one known pad field, so duplicate that code as needed. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/18c0b4eccdc86ffb7eccc2c6facfe382537ab877
  • Add comments about the need to avoid uninitialized bits in datatype values. There was already one recommendation in the documentation about writing C functions to ensure padding bytes are zeroes, but make it stronger. Also fix an example that was still using direct assignment to a varlena length word, which no longer works since the varvarlena changes. http://git.postgresql.org/pg/commitdiff/4f6c75b541385eb2d48f7ef62c1c323ec2642134
  • Make a quick copy-editing pass over the 9.1 release notes. Also remove the material about this being an alpha release. The notes still need a lot of work, but they're more or less presentable as a beta version now. http://git.postgresql.org/pg/commitdiff/bb1051eb2d5eef060b64788cbec8459c46427fca
  • Tag 9.1beta1. http://git.postgresql.org/pg/commitdiff/993c5e59047dd568d4831f7ec5c6199acd21f17f
  • Rewrite pg_size_pretty() to avoid compiler bug. Convert it to use successive shifts right instead of increasing a divisor. This is probably a tad more efficient than the original coding, and it's nicer-looking than the previous patch because we don't need a special case to avoid overflow in the last branch. But the real reason to do it is to avoid a Solaris compiler bug, as per results from buildfarm member moa. http://git.postgresql.org/pg/commitdiff/fd2e2d09aa1d5ba198e09e6d936ff1bba7f62895
  • Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum(). VACUUM was willing to remove a committed-dead tuple immediately if it was deleted by the same transaction that inserted it. The idea is that such a tuple could never have been visible to any other transaction, so we don't need to keep it around to satisfy MVCC snapshots. However, there was already an exception for tuples that are part of an update chain, and this exception created a problem: we might remove TOAST tuples (which are never part of an update chain) while their parent tuple stayed around (if it was part of an update chain). This didn't pose a problem for most things, since the parent tuple is indeed dead: no snapshot will ever consider it visible. But MVCC-safe CLUSTER had a problem, since it will try to copy RECENTLY_DEAD tuples to the new table. It then has to copy their TOAST data too, and would fail if VACUUM had already removed the toast tuples. Easiest fix is to get rid of the special case for xmin == xmax. This may delay reclaiming dead space for a little bit in some cases, but it's by far the most reliable way to fix the issue. Per bug #5998 from Mark Reid. Back-patch to 8.3, which is the oldest version with MVCC-safe CLUSTER. http://git.postgresql.org/pg/commitdiff/44e4bbf75d56e643b6afefd5cdcffccb68cce414
  • Make CLUSTER lock the old table's toast table before copying data. We must lock out autovacuuming of the old toast table before computing the OldestXmin horizon we will use. Otherwise, autovacuum could start on the toast table later, compute a later OldestXmin horizon, and remove as DEAD toast tuples that we still need (because we think their parent tuples are only RECENTLY_DEAD). Per further thought about bug #5998. http://git.postgresql.org/pg/commitdiff/83b7584944b3a9df064cccac06822093f1a83793

Magnus Hagander a poussé :

Heikki Linnakangas a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Bruce Momjian sent in a patch to correct the case of some status messages for Sync Rep.
  • Alvaro Herrera sent in a patch to the docs makefile to add HISTORY to the default build.
  • Merlin Moncure sent in a patch to fix a bug in tsearch/spell.c where ALLOC_CHUNK_LIMIT_RATIO could be too large, which would waste space in malloc'ed blocks.
  • Heikki Linnakangas sent in another revision of a patch to fix a memory leak in FDW.
  • Dan Ports sent in a patch to add comments about memory ordering in SSI.
  • Peter Eisentraut sent in a patch to add a pg_upgrade check.
  • Zoltan Boszormenyi sent in a WIP patch to enable cross-column statistics and extra expression statistics.
  • Noah Misch sent in another revision of the patch to fix an incompatibility between ALTER TYPE DROP where there is a composite-type column and pg_upgrade.
  • Gabriele Bartolini sent in a patch to smooth replication during VACUUM FULL.
  • Kevin Grittner sent in another revision of the patch to fix DDL with SSI.