← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/backend/optimizer/util/plancat.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/optimizer/util/plancat.c
427
427
                         * minimum size estimate of 10 pages.  The idea here is to avoid
428
428
                         * assuming a newly-created table is really small, even if it
429
429
                         * currently is, because that may not be true once some data gets
430
 
                         * loaded into it.      Once a vacuum or analyze cycle has been done
 
430
                         * loaded into it.  Once a vacuum or analyze cycle has been done
431
431
                         * on it, it's more reasonable to believe the size is somewhat
432
432
                         * stable.
433
433
                         *
434
434
                         * (Note that this is only an issue if the plan gets cached and
435
 
                         * used again after the table has been filled.  What we're trying
 
435
                         * used again after the table has been filled.  What we're trying
436
436
                         * to avoid is using a nestloop-type plan on a table that has
437
437
                         * grown substantially since the plan was made.  Normally,
438
438
                         * autovacuum/autoanalyze will occur once enough inserts have
441
441
                         * such as temporary tables.)
442
442
                         *
443
443
                         * We approximate "never vacuumed" by "has relpages = 0", which
444
 
                         * means this will also fire on genuinely empty relations.      Not
 
444
                         * means this will also fire on genuinely empty relations.  Not
445
445
                         * great, but fortunately that's a seldom-seen case in the real
446
446
                         * world, and it shouldn't degrade the quality of the plan too
447
447
                         * much anyway to err in this direction.
786
786
                return false;
787
787
 
788
788
        /*
789
 
         * OK to fetch the constraint expressions.      Include "col IS NOT NULL"
 
789
         * OK to fetch the constraint expressions.  Include "col IS NOT NULL"
790
790
         * expressions for attnotnull columns, in case we can refute those.
791
791
         */
792
792
        constraint_pred = get_relation_constraints(root, rte->relid, rel, true);
834
834
 * Exception: if there are any dropped columns, we punt and return NIL.
835
835
 * Ideally we would like to handle the dropped-column case too.  However this
836
836
 * creates problems for ExecTypeFromTL, which may be asked to build a tupdesc
837
 
 * for a tlist that includes vars of no-longer-existent types.  In theory we
 
837
 * for a tlist that includes vars of no-longer-existent types.  In theory we
838
838
 * could dig out the required info from the pg_attribute entries of the
839
839
 * relation, but that data is not readily available to ExecTypeFromTL.
840
840
 * For now, we don't apply the physical-tlist optimization when there are