diff options
| -rw-r--r-- | doc/src/sgml/maintenance.sgml | 2 | ||||
| -rw-r--r-- | doc/src/sgml/ref/create_table.sgml | 4 | ||||
| -rw-r--r-- | doc/src/sgml/ref/createuser.sgml | 2 |
3 files changed, 4 insertions, 4 deletions
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 38952ba8399..de71cb456a5 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -185,7 +185,7 @@ never issue <command>VACUUM FULL</command>. In this approach, the idea is not to keep tables at their minimum size, but to maintain steady-state usage of disk space: each table occupies space equivalent to its - minimum size plus however much space gets used up between vacuumings. + minimum size plus however much space gets used up between vacuum runs. Although <command>VACUUM FULL</command> can be used to shrink a table back to its minimum size and return the disk space to the operating system, there is not much point in this if the table will just grow again in the diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index 9b349eee3cc..e1e9b7db204 100644 --- a/doc/src/sgml/ref/create_table.sgml +++ b/doc/src/sgml/ref/create_table.sgml @@ -1478,7 +1478,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM </listitem> </varlistentry> - <varlistentry id="reloption-autovacuum-vauum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor"> + <varlistentry id="reloption-autovacuum-vacuum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor"> <term><literal>autovacuum_vacuum_scale_factor</literal>, <literal>toast.autovacuum_vacuum_scale_factor</literal> (<type>floating point</type>) <indexterm> <primary><varname>autovacuum_vacuum_scale_factor</varname> </primary> @@ -1538,7 +1538,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM </listitem> </varlistentry> - <varlistentry id="reloption-autovacuum-vauum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit"> + <varlistentry id="reloption-autovacuum-vacuum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit"> <term><literal>autovacuum_vacuum_cost_limit</literal>, <literal>toast.autovacuum_vacuum_cost_limit</literal> (<type>integer</type>) <indexterm> <primary><varname>autovacuum_vacuum_cost_limit</varname></primary> diff --git a/doc/src/sgml/ref/createuser.sgml b/doc/src/sgml/ref/createuser.sgml index 9d24df8b7a8..f43b4a4adaa 100644 --- a/doc/src/sgml/ref/createuser.sgml +++ b/doc/src/sgml/ref/createuser.sgml @@ -44,7 +44,7 @@ PostgreSQL documentation If you wish to create a new superuser, you must connect as a superuser, not merely with <literal>CREATEROLE</literal> privilege. Being a superuser implies the ability to bypass all access permission - checks within the database, so superuserdom should not be granted lightly. + checks within the database, so superuser access should not be granted lightly. </para> <para> |