database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Copy editing of the replication origins patch.

Browse Source 
Michael Paquier and myself.
This commit is contained in:
Andres Freund
2015-05-01 12:22:13 +02:00
parent 1db12da85b
commit 2b22795b32
4 changed files with 22 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/sgml/func.sgml
View File

@ -17086,9 +17086,8 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<parameter>internal_id</parameter> <type>oid</type>
</entry>
<entry>
Lookup replication origin by name and return the internal
oid. If no corresponding replication origin is found a error
is thrown.
Lookup replication origin by name and return the internal id. If no
corresponding replication origin is found an error is thrown.
</entry>
</row>

24
doc/src/sgml/replication-origins.sgml
View File

@ -22,14 +22,14 @@
</para>
<para>
Replication origins consist out of a name and a oid. The name, which
is what should be used to refer to the origin across systems, is
free-form text. It should be used in a way that makes conflicts
between replication origins created by different replication
solutions unlikely; e.g. by prefixing the replication solution's
name to it. The oid is used only to avoid having to store the long
version in situations where space efficiency is important. It should
never be shared between systems.
Replication origins consist out of a name and an <type>oid</type>. The name,
which is what should be used to refer to the origin across systems, is
free-form <type>text</type>. It should be used in a way that makes conflicts
between replication origins created by different replication solutions
unlikely; e.g. by prefixing the replication solution's name to it.
The <type>oid</type> is used only to avoid having to store the long version
in situations where space efficiency is important. It should never be shared
between systems.
</para>
<para>
@ -61,11 +61,11 @@
timestamp of every source transaction can be configured on a per
transaction basis using
<link linkend="pg-replication-origin-xact-setup"><function>pg_replication_origin_xact_setup()</function></link>.
If that's done replication progress will be persist in a crash safe
If that's done replication progress will persist in a crash safe
manner. Replay progress for all replication origins can be seen in the
<link linkend="catalog-pg-replication-origin-status">
<structname>pg_replication_origin_status</structname>
</link> view. A individual origin's progress, e.g. when resuming
</link> view. An individual origin's progress, e.g. when resuming
replication, can be acquired using
<link linkend="pg-replication-origin-progress"><function>pg_replication_origin_progress()</function></link>
for any origin or
@ -75,9 +75,9 @@
<para>
In more complex replication topologies than replication from exactly one
system to one other, another problem can be that, that it is hard to avoid
system to one other, another problem can be that it is hard to avoid
replicating replayed rows again. That can lead both to cycles in the
replication and inefficiencies. Replication origins provide a optional
replication and inefficiencies. Replication origins provide an optional
mechanism to recognize and prevent that. When configured using the functions
referenced in the previous paragraph, every change and transaction passed to
output plugin callbacks (see <xref linkend="logicaldecoding-output-plugin">)