not requiring a table scan). If that is different from

<structfield>relpages</structfield> then

<structfield>reltuples</structfield> is scaled accordingly to

arrive at a current number-of-rows estimate. Inthis case the value of

arrive at a current number-of-rows estimate. Inthe example above, the value of

<structfield>relpages</structfield> is up-to-date so the rows estimate is

the same as <structfield>reltuples</structfield>.

</para>

When this option is used,

<productname>&productname;</> must perform two scans of the table, and in

addition it must wait for all existing transactions that could potentially

use the index to terminate. Thus

modify oruse the index to terminate. Thus

this method requires more total work than a standard index build and takes

significantly longer to complete. However, since it allows normal

operations to continue while the index is built, this method is useful for

<para>

In a concurrent index build, the index is actually entered into

the system catalogs in one transaction, then two table scans occur in

two more transactions. Any transaction active when the second table

scan starts can block concurrent index creation until it completes,

even transactions that only reference the table after the second table

scan starts. Concurrent index creation serially waits for each old

transaction to complete using the method outlined in section <xref

linkend="view-pg-locks">.

two more transactions. Before each table scan, the index build must

wait for existing transactions that have modified the table to terminate.

After the second scan, the index build must wait for any transactions

that have a snapshot (see <xref linkend="mvcc">) predating the second

scan to terminate. Then finally the index can be marked ready for use,

and the <command>CREATE INDEX</> command terminates.

Even then, however, the index may not be immediately usable for queries:

in the worst case, it cannot be used as long as transactions exist that

predate the start of the index build.

</para>

<para>

<listitem>

<para>

The maximum number of seconds to wait when waiting for startup or

shutdown to complete. The default is 60 seconds.

shutdown to complete. Defaults to the value of the

<envar>PGCTLTIMEOUT</> environment variable or, if not set, to 60

seconds.

</para>

</listitem>

</varlistentry>

<title>Environment</title>

<variablelist>

<varlistentry>

<term><envar>PGCTLTIMEOUT</envar></term>

<listitem>

<para>

Default limit on the number of seconds to wait when waiting for startup

or shutdown to complete. If not set, the default is 60 seconds.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><envar>PGDATA</envar></term>

<listitem>

<!--

2015-06-21 [ad89a5d] Alvaro..:Add transforms to pg_get_object_address and fr..

2014-12-23 [7eca575] Alvaro..:get_object_address: separate domain constraints..

-->

<para>

Support comments on <link linkend="SQL-CREATEDOMAIN">domain

<row>

<entry><varname>SEMMNI</></>

<entry>Maximum number of semaphore identifiers (i.e., sets)</>

<entry>at least <literal>ceil((max_connections + autovacuum_max_workers +4) / 16)</literal></>

<entry>at least <literal>ceil((max_connections + autovacuum_max_workers +max_worker_processes + 5) / 16)</literal></>

</row>

<row>

<entry><varname>SEMMNS</></>

<entry>Maximum number of semaphores system-wide</>

<entry><literal>ceil((max_connections + autovacuum_max_workers +4) / 16) * 17</literal> plus room for other applications</>

<entry><literal>ceil((max_connections + autovacuum_max_workers +max_worker_processes + 5) / 16) * 17</literal> plus room for other applications</>

</row>

<row>

</para>

<para>

<productname>&productname;</> uses one semaphore per allowed connection

(<xref linkend="guc-max-connections">) and allowed autovacuum worker

process (<xref linkend="guc-autovacuum-max-workers">), in sets of 16.

<productname>PostgreSQL</> uses one semaphore per allowed connection

(<xref linkend="guc-max-connections">), allowed autovacuum worker process

(<xref linkend="guc-autovacuum-max-workers">) and allowed background

process (<xref linkend="guc-max-worker-processes">), in sets of 16.

Each such set will

also contain a 17th semaphore which contains a <quote>magic

number</quote>, to detect collision with semaphore sets used by

other applications. The maximum number of semaphores in the system

is set by <varname>SEMMNS</>, which consequently must be at least

as high as <varname>max_connections</> plus

<varname>autovacuum_max_workers</>, plus one extra for each 16

<varname>autovacuum_max_workers</> plus <varname>max_worker_processes</>,

plus one extra for each 16

allowed connections plus workers (see the formula in <xref

linkend="sysvipc-parameters">). The parameter <varname>SEMMNI</>

determines the limit on the number of semaphore sets that can

exist on the system at one time. Hence this parameter must be at

least <literal>ceil((max_connections + autovacuum_max_workers +4) / 16)</>.

least <literal>ceil((max_connections + autovacuum_max_workers +max_worker_processes + 5) / 16)</>.

Lowering the number

of allowed connections is a temporary workaround for failures,

which are usually confusingly worded <quote>No space

break;

caseCHR('u'):

c=lexdigits(v,16,4,4);

if (ISERR()||c<CHR_MIN||c>CHR_MAX)

if (ISERR()||!CHR_IS_IN_RANGE(c))

FAILW(REG_EESCAPE);

RETV(PLAIN,c);

break;

caseCHR('U'):

c=lexdigits(v,16,8,8);

if (ISERR()||c<CHR_MIN||c>CHR_MAX)

if (ISERR()||!CHR_IS_IN_RANGE(c))

FAILW(REG_EESCAPE);

RETV(PLAIN,c);

break;

caseCHR('x'):

NOTE(REG_UUNPORT);

c=lexdigits(v,16,1,255);/* REs >255 long outside spec */

if (ISERR()||c<CHR_MIN||c>CHR_MAX)

if (ISERR()||!CHR_IS_IN_RANGE(c))

FAILW(REG_EESCAPE);

RETV(PLAIN,c);

break;