database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-22 23:02:54 +03:00
Code

doc: Fix some grammar and inconsistent tags

Browse Source 
Author: Ekaterina Kiryanova, Elena Indrupskaya, Oleg Sibiryakov, Maxim
Yablokov
Discussion: https://postgr.es/m/4c2a430b-32e2-44e2-aeca-03b7db6824e4@postgrespro.ru
This commit is contained in:
Michael Paquier 2023-10-23 09:58:55 +09:00
parent 5e4dacb987
commit 40ebc41576
7 changed files with 27 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/src/sgml/catalogs.sgml
View File

@ -7943,7 +7943,8 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
disk and apply at once after the transaction is committed on the
publisher and received by the subscriber,
<literal>p</literal> = apply changes directly using a parallel apply
worker if available (same as 't' if no worker is available)
worker if available (same as <literal>t</literal> if no worker is
available)
</para></entry>
</row>

4
doc/src/sgml/custom-rmgr.sgml
View File

@ -96,8 +96,8 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
</para>
<note>
<para>
The extension must remain in shared_preload_libraries as long as any
custom WAL records may exist in the system. Otherwise
The extension must remain in <varname>shared_preload_libraries</varname>
as long as any custom WAL records may exist in the system. Otherwise
<productname>PostgreSQL</productname> will not be able to apply or decode
the custom WAL records, which may prevent the server from starting.
</para>

6
doc/src/sgml/ecpg.sgml
View File

@ -1506,9 +1506,9 @@ EXEC SQL TYPE serial_t IS long;
</para>
<para>
Any word you declare as a typedef cannot be used as an SQL keyword
in <literal>EXEC SQL</literal> commands later in the same program.
For example, this won't work:
Any word you declare as a <literal>typedef</literal> cannot be used as
an SQL keyword in <literal>EXEC SQL</literal> commands later in the same
program. For example, this won't work:
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
typedef int start;

4
doc/src/sgml/installation.sgml
View File

@ -2743,8 +2743,8 @@ ninja install
<para>
The default backend Meson uses is ninja and that should suffice for
most use cases. However, if you'd like to fully integrate with Visual
Studio, you can set the <option>BACKEND</option> to
<command>vs</command>.
Studio, you can set the <replaceable>BACKEND</replaceable> to
<literal>vs</literal>.
</para>
</listitem>
</varlistentry>

9
doc/src/sgml/logicaldecoding.sgml
View File

@ -326,11 +326,12 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU
will work but only while the connection is alive (for example a node
restart would break it). Then, the primary may delete system catalog rows
that could be needed by the logical decoding on the standby (as it does
not know about the catalog_xmin on the standby). Existing logical slots
on standby also get invalidated if <varname>wal_level</varname> on the
primary is reduced to less than <literal>logical</literal>.
not know about the <literal>catalog_xmin</literal> on the standby).
Existing logical slots on standby also get invalidated if
<varname>wal_level</varname> on the primary is reduced to less than
<literal>logical</literal>.
This is done as soon as the standby detects such a change in the WAL stream.
It means that, for walsenders which are lagging (if any), some WAL records up
It means that, for walsenders that are lagging (if any), some WAL records up
to the <varname>wal_level</varname> parameter change on the primary won't be
decoded.
</para>

20
doc/src/sgml/protocol.sgml
View File

@ -2437,11 +2437,12 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<term>Int32</term>
<listitem>
<para>
The standby's current global xmin, excluding the catalog_xmin from any
replication slots. If both this value and the following
catalog_xmin are 0 this is treated as a notification that hot standby
feedback will no longer be sent on this connection. Later non-zero
messages may reinitiate the feedback mechanism.
The standby's current global <literal>xmin</literal>, excluding the
<literal>catalog_xmin</literal> from any replication slots. If both
this value and the following <literal>catalog_xmin</literal>
are 0, this is treated as a notification that hot standby feedback
will no longer be sent on this connection. Later non-zero messages
may reinitiate the feedback mechanism.
</para>
</listitem>
</varlistentry>
@ -2450,7 +2451,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<term>Int32</term>
<listitem>
<para>
The epoch of the global xmin xid on the standby.
The epoch of the global <literal>xmin</literal> xid on the standby.
</para>
</listitem>
</varlistentry>
@ -2459,8 +2460,9 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<term>Int32</term>
<listitem>
<para>
The lowest catalog_xmin of any replication slots on the standby. Set to 0
if no catalog_xmin exists on the standby or if hot standby feedback is being
The lowest <literal>catalog_xmin</literal> of any replication
slots on the standby. Set to 0 if no <literal>catalog_xmin</literal>
exists on the standby or if hot standby feedback is being
disabled.
</para>
</listitem>
@ -2470,7 +2472,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<term>Int32</term>
<listitem>
<para>
The epoch of the catalog_xmin xid on the standby.
The epoch of the <literal>catalog_xmin</literal> xid on the standby.
</para>
</listitem>
</varlistentry>

4
doc/src/sgml/xact.sgml
View File

@ -70,7 +70,7 @@
</para>
<para>
In addition to <literal>vxid</literal> and <type>xid</type>,
In addition to <literal>vxid</literal> and <literal>xid</literal>,
prepared transactions are also assigned Global Transaction
Identifiers (<acronym>GID</acronym>). GIDs are string literals up
to 200 bytes long, which must be unique amongst other currently
@ -121,7 +121,7 @@
<para>
Subtransactions can be started explicitly using the
<command>SAVEPOINT</command> command, but can also be started in
other ways, such as PL/pgSQL's <command>EXCEPTION</command> clause.
other ways, such as PL/pgSQL's <literal>EXCEPTION</literal> clause.
PL/Python and PL/TCL also support explicit subtransactions.
Subtransactions can also be started from other subtransactions.
The top-level transaction and its child subtransactions form a