← Back to branch summary

~ubuntu-branches/ubuntu/precise/postgresql-8.4/precise-proposed

« back to all changes in this revision

Viewing changes to src/backend/access/hash/hashsort.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-29 14:47:30 UTC
  • mfrom: (1.4.4)
  • Revision ID: package-import@ubuntu.com-20140729144730-gbpktxf1uyuc90kq
Tags: 8.4.22-0ubuntu0.12.04
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - 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/docs/current/static/release-8-4-22.html
* Drop pg_regress patch to run tests with socket in /tmp, obsolete with
  above upstream changes and not applicable any more.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/access/hash/hashsort.c
8
8
 * thrashing.  We use tuplesort.c to sort the given index tuples into order.
9
9
 *
10
10
 * Note: if the number of rows in the table has been underestimated,
11
 
 * bucket splits may occur during the index build.      In that case we'd
 
11
 * bucket splits may occur during the index build.  In that case we'd
12
12
 * be inserting into two or more buckets for each possible masked-off
13
13
 * hash code value.  That's no big problem though, since we'll still have
14
14
 * plenty of locality of access.
52
52
        hspool->index = index;
53
53
 
54
54
        /*
55
 
         * Determine the bitmask for hash code values.  Since there are currently
 
55
         * Determine the bitmask for hash code values.  Since there are currently
56
56
         * num_buckets buckets in the index, the appropriate mask can be computed
57
57
         * as follows.
58
58
         *