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

« back to all changes in this revision

Viewing changes to doc/src/sgml/ref/reindex.sgml

  • 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
* 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:
46
46
 
47
47
    <listitem>
48
48
     <para>
49
 
      An index has become <quote>bloated</>, that it is contains many
 
49
      An index has become <quote>bloated</>, that is it contains many
50
50
      empty or nearly-empty pages.  This can occur with B-tree indexes in
51
51
      <productname>PostgreSQL</productname> under certain uncommon access
52
52
      patterns. <command>REINDEX</command> provides a way to reduce
203
203
   but not reads of the index's parent table.  It also takes an exclusive lock
204
204
   on the specific index being processed, which will block reads that attempt
205
205
   to use that index.  In contrast, <command>DROP INDEX</> momentarily takes
206
 
   exclusive lock on the parent table, blocking both writes and reads.  The
 
206
   an exclusive lock on the parent table, blocking both writes and reads.  The
207
207
   subsequent <command>CREATE INDEX</> locks out writes but not reads; since
208
208
   the index is not there, no read will attempt to use it, meaning that there
209
209
   will be no blocking but reads might be forced into expensive sequential