From f18858dc72daf64bedb4bfc946e496fa11e972c9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 14 Jul 2014 20:37:00 -0400
Subject: [PATCH] doc: small fixes for REINDEX reference page
From: Josh Kupershmidt <schmiddy@gmail.com>
---
doc/src/sgml/ref/reindex.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 722266563eb..a795dfa3256 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -46,7 +46,7 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
<listitem>
<para>
- An index has become <quote>bloated</>, that it is contains many
+ An index has become <quote>bloated</>, that is it contains many
empty or nearly-empty pages. This can occur with B-tree indexes in
<productname>PostgreSQL</productname> under certain uncommon access
patterns. <command>REINDEX</command> provides a way to reduce
@@ -203,7 +203,7 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
but not reads of the index's parent table. It also takes an exclusive lock
on the specific index being processed, which will block reads that attempt
to use that index. In contrast, <command>DROP INDEX</> momentarily takes
- exclusive lock on the parent table, blocking both writes and reads. The
+ an exclusive lock on the parent table, blocking both writes and reads. The
subsequent <command>CREATE INDEX</> locks out writes but not reads; since
the index is not there, no read will attempt to use it, meaning that there
will be no blocking but reads might be forced into expensive sequential
--
GitLab