summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 6cea447)
raw | patch | inline | side by side (parent: 6cea447)
| author | Peter Eisentraut <peter@eisentraut.org> | |
| Fri, 16 Jul 2021 08:35:38 +0000 (10:35 +0200) | ||
| committer | Peter Eisentraut <peter@eisentraut.org> | |
| Fri, 16 Jul 2021 10:39:45 +0000 (12:39 +0200) |
13 files changed:
diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml
index f32208b550442fba93d0ada34d94d8f6a4b82edc..f900a01b82424f7c477fd2ce63b79fda8460a6da 100644 (file)
--- a/doc/src/sgml/bki.sgml
+++ b/doc/src/sgml/bki.sgml
<filename>reformat_dat_file.pl</filename> can be adapted to perform
many kinds of bulk changes. Look for its block comments showing where
one-off code can be inserted. In the following example, we are going
- to consolidate two boolean fields in <structname>pg_proc</structname>
+ to consolidate two Boolean fields in <structname>pg_proc</structname>
into a char field:
<orderedlist>
index d1194def8200ddb172f78e057cedc64e1cad0197..c21fe67eb7a68f479f9cc9a9aab322c2f0bf9a27 100644 (file)
<structfield>vartype</structfield> = <type>RECORD</type>,
and <literal>wholerow<replaceable>N</replaceable></literal>
for a whole-row <structname>Var</structname> with
- <structfield>vartype</structfield> equal to the table's declared rowtype.
+ <structfield>vartype</structfield> equal to the table's declared row type.
Re-use these names when you can (the planner will combine duplicate
requests for identical junk columns). If you need another kind of
junk column besides these, it might be wise to choose a name prefixed
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6388385edc56f5dea81fe33d5146657216ea910c..ac6347a97115d44d682049caac4206aeff2e164f 100644 (file)
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
sending a <systemitem>SIGHUP</systemitem> signal to the postmaster
process, which in turn sends <systemitem>SIGHUP</systemitem> to each
of its children.) You can use the
- <link linkend="view-pg-file-settings">pg_file_settings</link> and
- <link linkend="view-pg-hba-file-rules">pg_hba_file_rules</link> views
+ <link linkend="view-pg-file-settings"><structname>pg_file_settings</structname></link> and
+ <link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link> views
to check the configuration files for possible errors, before reloading.
</para></entry>
</row>
diff --git a/doc/src/sgml/gist.sgml b/doc/src/sgml/gist.sgml
index f22efd1f6e898e8bcba192a12fe2a6d56355f3e2..c79ce850e9463ccb7dcfc4d0837c0eec97d98ad9 100644 (file)
--- a/doc/src/sgml/gist.sgml
+++ b/doc/src/sgml/gist.sgml
<para>
Depending on which operators you have included in the class, the data
type of <varname>query</varname> could vary with the operator, since it will
- be whatever type is on the righthand side of the operator, which might
- be different from the indexed data type appearing on the lefthand side.
+ be whatever type is on the right-hand side of the operator, which might
+ be different from the indexed data type appearing on the left-hand side.
(The above code skeleton assumes that only one type is possible; if
not, fetching the <varname>query</varname> argument value would have to depend
on the operator.) It is recommended that the SQL declaration of
index ceee5f3580c928164ff4c23e7b655f90fab42d2d..cf359fa9ffd9701541ddbd8accd28120debb8af2 100644 (file)
</para>
<para>
- The <literal>indexUnchanged</literal> boolean value gives a hint
+ The <literal>indexUnchanged</literal> Boolean value gives a hint
about the nature of the tuple to be indexed. When it is true,
the tuple is a duplicate of some existing tuple in the index. The
new tuple is a logically unchanged successor MVCC tuple version. This
code, it's better to inspect <parameter>prop</parameter>.
If the <structfield>amproperty</structfield> method returns <literal>true</literal> then
it has determined the property test result: it must set <literal>*res</literal>
- to the boolean value to return, or set <literal>*isnull</literal>
+ to the Boolean value to return, or set <literal>*isnull</literal>
to <literal>true</literal> to return a NULL. (Both of the referenced variables
are initialized to <literal>false</literal> before the call.)
If the <structfield>amproperty</structfield> method returns <literal>false</literal> then
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index 1b5103e2694b5b5dca2a86bd5305b17324f09821..673c70c3bb85f240754be9e9dc77090eb5870700 100644 (file)
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -617,7 +617,7 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
<para>
<command>UPDATE</command> statements may use subscripting in the
<literal>SET</literal> clause to modify <type>jsonb</type> values. Subscript
- paths must be traversible for all affected values insofar as they exist. For
+ paths must be traversable for all affected values insofar as they exist. For
instance, the path <literal>val['a']['b']['c']</literal> can be traversed all
the way to <literal>c</literal> if every <literal>val</literal>,
<literal>val['a']</literal>, and <literal>val['a']['b']</literal> is an
index 2e4f615a6591b80d382771b7fddfb71d26cae83e..56689ba8730ec106290ebf84d2e13d6e3553c4f7 100644 (file)
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
There is no environment variable equivalent to this option, and no
facility for looking it up in <filename>.pgpass</filename>. It can be
used in a service file connection definition. Users with
- more sophisticated uses should consider using openssl engines and
+ more sophisticated uses should consider using <productname>OpenSSL</productname> engines and
tools like PKCS#11 or USB crypto offload devices.
</para>
</listitem>
<para>
While the pipeline API was introduced in
<productname>PostgreSQL</productname> 14, it is a client-side feature
- which doesn't require special server support, and works on any server
+ which doesn't require special server support and works on any server
that supports the v3 extended query protocol.
</para>
are being performed in rapid succession. There is usually less benefit
in using pipelined commands when each query takes many multiples of the client/server
round-trip time to execute. A 100-statement operation run on a server
- 300ms round-trip-time away would take 30 seconds in network latency alone
- without pipelining; with pipelining it may spend as little as 0.3s waiting for
+ 300 ms round-trip-time away would take 30 seconds in network latency alone
+ without pipelining; with pipelining it may spend as little as 0.3 s waiting for
results from the server.
</para>
<para>
Each registered event handler is associated with two pieces of data,
known to <application>libpq</application> only as opaque <literal>void *</literal>
- pointers. There is a <firstterm>passthrough</firstterm> pointer that is provided
+ pointers. There is a <firstterm>pass-through</firstterm> pointer that is provided
by the application when the event handler is registered with a
- <structname>PGconn</structname>. The passthrough pointer never changes for the
+ <structname>PGconn</structname>. The pass-through pointer never changes for the
life of the <structname>PGconn</structname> and all <structname>PGresult</structname>s
generated from it; so if used, it must point to long-lived data.
In addition there is an <firstterm>instance data</firstterm> pointer, which starts
<xref linkend="libpq-PQsetInstanceData"/>,
<xref linkend="libpq-PQresultInstanceData"/> and
<function>PQsetResultInstanceData</function> functions. Note that
- unlike the passthrough pointer, instance data of a <structname>PGconn</structname>
+ unlike the pass-through pointer, instance data of a <structname>PGconn</structname>
is not automatically inherited by <structname>PGresult</structname>s created from
- it. <application>libpq</application> does not know what passthrough
+ it. <application>libpq</application> does not know what pass-through
and instance data pointers point to (if anything) and will never attempt
to free them — that is the responsibility of the event handler.
</para>
index 002efc86b433f386ff743d7eedf3825f7d90b9b6..89b8090b79f3a42d71224c09e16a9d4b416b6634 100644 (file)
Similar to spill-to-disk behavior, streaming is triggered when the total
amount of changes decoded from the WAL (for all in-progress transactions)
exceeds the limit defined by <varname>logical_decoding_work_mem</varname> setting.
- At that point, the largest toplevel transaction (measured by the amount of memory
+ At that point, the largest top-level transaction (measured by the amount of memory
currently used for decoded changes) is selected and streamed. However, in
some cases we still have to spill to disk even if streaming is enabled
because we exceed the memory threshold but still have not decoded the
index 643e1ad49fd887e540dae59d9b51ed209aafefaf..74a58a916c15ae8fe64e69e0e20cbc8c442c8288 100644 (file)
@@ -2647,7 +2647,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
Number of transactions spilled to disk once the memory used by
logical decoding to decode changes from WAL has exceeded
<literal>logical_decoding_work_mem</literal>. The counter gets
- incremented for both toplevel transactions and subtransactions.
+ incremented for both top-level transactions and subtransactions.
</para></entry>
</row>
@@ -2684,7 +2684,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
plugin after the memory used by logical decoding to decode changes
from WAL for this slot has exceeded
<literal>logical_decoding_work_mem</literal>. Streaming only
- works with toplevel transactions (subtransactions can't be streamed
+ works with top-level transactions (subtransactions can't be streamed
independently), so the counter is not incremented for subtransactions.
</para></entry>
</row>
@@ -2720,7 +2720,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</para>
<para>
Number of decoded transactions sent to the decoding output plugin for
- this slot. This counts toplevel transactions only, and is not incremented
+ this slot. This counts top-level transactions only, and is not incremented
for subtransactions. Note that this includes the transactions that are
streamed and/or spilled.
</para></entry>
index 542b197282cdcc4f206d297f4f39bde7822f06cd..70b28a92c107a8754c26cb877697986882b2a575 100644 (file)
The statistics gathered by the module are made available via a
view named <structname>pg_stat_statements</structname>. This view
contains one row for each distinct combination of database ID, user
- ID, query ID and whether it's a top level statement or not (up to
+ ID, query ID and whether it's a top-level statement or not (up to
the maximum number of distinct statements that the module can track).
The columns of the view are shown in
<xref linkend="pgstatstatements-columns"/>.
<structfield>toplevel</structfield> <type>bool</type>
</para>
<para>
- True if the query was executed as a top level statement
+ True if the query was executed as a top-level statement
(always true if <varname>pg_stat_statements.track</varname> is set to
<literal>top</literal>)
</para></entry>
index c5e5e84e06bd78c3f56ee069942d716646c81645..1c7f48938bc6783deaa8771c94ddecec3d816e5e 100644 (file)
@@ -1002,7 +1002,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
</para>
<para>
If <literal>FINALIZE</literal> is specified, a previous
- <literal>DETACH CONCURRENTLY</literal> invocation that was cancelled or
+ <literal>DETACH CONCURRENTLY</literal> invocation that was canceled or
interrupted is completed.
At most one partition in a partitioned table can be pending detach at
a time.
index da5330685727e2330c8634da1d6301e67cc297b8..fcab5c0d51a237a69f2f026028ab38979e2ac133 100644 (file)
</para>
<para>
The <command>\if</command> and <command>\elif</command> commands read
- their argument(s) and evaluate them as a boolean expression. If the
+ their argument(s) and evaluate them as a Boolean expression. If the
expression yields <literal>true</literal> then processing continues
normally; otherwise, lines are skipped until a
matching <command>\elif</command>, <command>\else</command>,
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 60f066d247390c4f50fa3ef8a74b5e4b001cec69..24e1c89503cbc12ef9aba4a92fb0f1152af01431 100644 (file)
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
<acronym>WAL</acronym> logs are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
- by altering the <option>--wal-segsize</option> initdb option). Each segment is
+ by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
<option>--with-wal-blocksize</option> configure option). The log record headers
are described in <filename>access/xlogrecord.h</filename>; the record