The process for an exclusive backup is mostly the same as for a
non-exclusive one, but it differs in a few key steps. This type of
backup can only be taken on a primary and does not allow concurrent
- backups. Moreover, because it writes a backup_label file on the
- master, it can cause the master to fail to restart automatically after
- a crash. On the other hand, the erroneous removal of a backup_label
- file from a backup or standby is a common mistake which can result
+ backups. Moreover, because it creates a backup label file, as
+ described below, it can block automatic restart of the master server
+ after a crash. On the other hand, the erroneous removal of this
+ file from a backup or standby is a common mistake, which can result
in serious data corruption. If it is necessary to use this method,
the following steps may be used.
As noted above, if the server crashes during the backup it may not be
- possible to restart until the <literal>backup_label> file has
+ possible to restart until the <filename>backup_label> file has
been manually deleted from the PGDATA directory. Note
that it is very important to never remove the
- <literal>backup_label> file when restoring a backup, because
+ <filename>backup_label> file when restoring a backup, because
this will result in corruption. Confusion about when it is appropriate
to remove this file is a common cause of data corruption when using this
method; be very certain that you remove the file only on an existing
lack of disk space, failure to call pg_stop_backup
will leave the server in backup mode indefinitely, causing future backups
to fail and increasing the risk of a restart failure during the time that
- <literal>backup_label> exists.
+ <filename>backup_label> exists.
-
<span class="marked">SQL Technical Report</span>
+
<span class="marked"><ulink url="http://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip">SQL Technical Report</ulink></span>
Part 6: SQL support for JavaScript Object
Notation (JSON)
- First Edition.
-
-
+ First Edition
Backward compatibility syntax for removing the oid
- system column. As oid system columns cannot be added anymore, this never
- has an effect.
+ system column. As oid system columns cannot be added
+ anymore, this never has an effect.
to be written safely to disk. This option causes
pg_checksums to return without waiting, which is
faster, but means that a subsequent operating system crash can leave
- the updated data folder corrupt. Generally, this option is useful
+ the updated data directory corrupt. Generally, this option is useful
for testing but should not be used on a production installation.
This option has no effect when using --check.
- Use the specified value of extra_float_digits when dumping
+ Use the specified value of when dumping
floating-point data, instead of the maximum available precision.
Routine dumps made for backup purposes should not use this option.
to be written safely to disk. This option causes
pg_rewind to return without waiting, which is
faster, but means that a subsequent operating system crash can leave
- the synchronized data folder corrupt. Generally, this option is
+ the synchronized data directory corrupt. Generally, this option is
useful for testing but should not be used when creating a production
installation.
- Because in "prepared" mode
pgbench reuses
- the parse analysis result for the second and subsequent query
- iteration,
pgbench runs faster in the- prepared mode than in other modes.
+ In the
prepared mode,
pgbench+ reuses the parse analysis result starting from the second query
+ iteration,
so pgbench runs faster+ than in other modes.
The default is simple query protocol. (See
When this option is used,
PostgreSQL will rebuild the
index without taking any locks that prevent concurrent inserts,
- updates, or deletes on the table; whereas a standard reindex build
+ updates, or deletes on the table; whereas a standard index rebuild
locks out writes (but not reads) on the table until it's done.
There are several caveats to be aware of when using this option
— see
of writes. This method is invoked by specifying the
CONCURRENTLY option of REINDEX. When this option
is used,
PostgreSQL must perform two scans of the table
- for each index that needs to be rebuild and in addition it must wait for
- all existing transactions that could potentially use the index to
- terminate. This method requires more total work than a standard index
+ for each index that needs to be rebuilt and wait for termination of
+ all existing transactions that could potentially use the index.
+ This method requires more total work than a standard index
rebuild and takes significantly longer to complete as it needs to wait
for unfinished transactions that might modify the index. However, since
- it allows normal operations to continue while the index is rebuilt, this
+ it allows normal operations to continue while the index is being rebuilt, this
method is useful for rebuilding indexes in a production environment. Of
course, the extra CPU, memory and I/O load imposed by the index rebuild
may slow down other operations.
- Rebuild a table while authorizing read and write operations on involved
- relations when performed:
+ Rebuild indexes for a table, without blocking read and write operations
+ on involved relations while reindexing is in progress:
REINDEX TABLE CONCURRENTLY my_broken_table;
projects / postgresql.git / commitdiff