database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Standardize "WAL location" terminology

Browse Source 
Other previously used terms were "WAL position" or "log position".
This commit is contained in:
Peter Eisentraut
2017-05-12 13:51:27 -04:00
parent c1a7f64b4a
commit d496a65790
19 changed files with 62 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/sgml/config.sgml
View File

@ -3312,7 +3312,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
to the primary or upstream standby, where it can be seen using the
<link linkend="monitoring-stats-views-table">
<literal>pg_stat_replication</></link> view. The standby will report
the last write-ahead log position it has written, the last position it
the last write-ahead log location it has written, the last position it
has flushed to disk, and the last position it has applied.
This parameter's
value is the maximum interval, in seconds, between reports. Updates are

2
doc/src/sgml/datatype.sgml
View File

@ -4635,7 +4635,7 @@ SELECT * FROM pg_attribute
standard comparison operators, like <literal>=</literal> and
<literal>&gt;</literal>. Two LSNs can be subtracted using the
<literal>-</literal> operator; the result is the number of bytes separating
those write-ahead log positions.
those write-ahead log locations.
</para>
</sect1>

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

@ -632,7 +632,7 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx,
its XID. Note however that it can be NULL when the message is
non-transactional and the XID was not assigned yet in the transaction
which logged the message. The <parameter>lsn</parameter> has WAL
position of the message. The <parameter>transactional</parameter> says
location of the message. The <parameter>transactional</parameter> says
if the message was sent as transactional or not.
The <parameter>prefix</parameter> is arbitrary null-terminated prefix
which can be used for identifying interesting messages for the current

22
doc/src/sgml/monitoring.sgml
View File

@ -1829,7 +1829,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
being generated, but would differ when the sender becomes idle. In
particular, when the standby has caught up completely,
<structname>pg_stat_replication</structname> shows the time taken to
write, flush and replay the most recent reported WAL position rather than
write, flush and replay the most recent reported WAL location rather than
zero as some users might expect. This is consistent with the goal of
measuring synchronous commit and transaction visibility delays for
recent write transactions.
@ -1865,7 +1865,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<row>
<entry><structfield>receive_start_lsn</></entry>
<entry><type>pg_lsn</></entry>
<entry>First write-ahead log position used when WAL receiver is
<entry>First write-ahead log location used when WAL receiver is
started</entry>
</row>
<row>
@ -1876,16 +1876,16 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<row>
<entry><structfield>received_lsn</></entry>
<entry><type>pg_lsn</></entry>
<entry>Last write-ahead log position already received and flushed to
disk, the initial value of this field being the first log position used
<entry>Last write-ahead log location already received and flushed to
disk, the initial value of this field being the first log location used
when WAL receiver is started</entry>
</row>
<row>
<entry><structfield>received_tli</></entry>
<entry><type>integer</></entry>
<entry>Timeline number of last write-ahead log position received and
<entry>Timeline number of last write-ahead log location received and
flushed to disk, the initial value of this field being the timeline
number of the first log position used when WAL receiver is started
number of the first log location used when WAL receiver is started
</entry>
</row>
<row>
@ -1901,12 +1901,12 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<row>
<entry><structfield>latest_end_lsn</></entry>
<entry><type>pg_lsn</></entry>
<entry>Last write-ahead log position reported to origin WAL sender</entry>
<entry>Last write-ahead log location reported to origin WAL sender</entry>
</row>
<row>
<entry><structfield>latest_end_time</></entry>
<entry><type>timestamp with time zone</></entry>
<entry>Time of last write-ahead log position reported to origin WAL sender</entry>
<entry>Time of last write-ahead log location reported to origin WAL sender</entry>
</row>
<row>
<entry><structfield>slot_name</></entry>
@ -1967,7 +1967,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<row>
<entry><structfield>received_lsn</></entry>
<entry><type>pg_lsn</></entry>
<entry>Last write-ahead log position received, the initial value of
<entry>Last write-ahead log location received, the initial value of
this field being 0</entry>
</row>
<row>
@ -1984,13 +1984,13 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<row>
<entry><structfield>latest_end_lsn</></entry>
<entry><type>pg_lsn</></entry>
<entry>Last write-ahead log position reported to origin WAL sender
<entry>Last write-ahead log location reported to origin WAL sender
</entry>
</row>
<row>
<entry><structfield>latest_end_time</></entry>
<entry><type>timestamp with time zone</></entry>
<entry>Time of last write-ahead log position reported to origin WAL
<entry>Time of last write-ahead log location reported to origin WAL
sender</entry>
</row>
</tbody>

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

@ -1724,7 +1724,7 @@ The commands accepted in walsender mode are:
<term><literal>consistent_point</literal> (<type>text</type>)</term>
<listitem>
<para>
The WAL position at which the slot became consistent. This is the
The WAL location at which the slot became consistent. This is the
earliest location from which streaming can start on this replication
slot.
</para>
@ -1764,7 +1764,7 @@ The commands accepted in walsender mode are:
<listitem>
<para>
Instructs server to start streaming WAL, starting at
WAL position <replaceable class="parameter">XXX/XXX</>.
WAL location <replaceable class="parameter">XXX/XXX</>.
If <literal>TIMELINE</literal> option is specified,
streaming starts on timeline <replaceable class="parameter">tli</>;
otherwise, the server's current timeline is selected. The server can
@ -1796,7 +1796,7 @@ The commands accepted in walsender mode are:
acknowledges this by also exiting COPY mode, the server sends a result
set with one row and two columns, indicating the next timeline in this
server's history. The first column is the next timeline's ID (type <type>int8</type>), and the
second column is the WAL position where the switch happened (type <type>text</type>). Usually,
second column is the WAL location where the switch happened (type <type>text</type>). Usually,
the switch position is the end of the WAL that was streamed, but there
are corner cases where the server can send some WAL from the old
timeline that it has not itself replayed before promoting. Finally, the
@ -2115,7 +2115,7 @@ The commands accepted in walsender mode are:
<listitem>
<para>
Instructs server to start streaming WAL for logical replication, starting
at WAL position <replaceable class="parameter">XXX/XXX</>. The server can
at WAL location <replaceable class="parameter">XXX/XXX</>. The server can
reply with an error, for example if the requested section of WAL has already
been recycled. On success, server responds with a CopyBothResponse
message, and then starts to stream WAL to the frontend.
@ -2147,7 +2147,7 @@ The commands accepted in walsender mode are:
<term><replaceable class="parameter">XXX/XXX</></term>
<listitem>
<para>
The WAL position to begin streaming at.
The WAL location to begin streaming at.
</para>
</listitem>
</varlistentry>

4
doc/src/sgml/ref/pg_waldump.sgml
View File

@ -85,7 +85,7 @@ PostgreSQL documentation
<term><option>--end=<replaceable>end</replaceable></option></term>
<listitem>
<para>
Stop reading at the specified log position, instead of reading to the
Stop reading at the specified WAL location, instead of reading to the
end of the log stream.
</para>
</listitem>
@ -144,7 +144,7 @@ PostgreSQL documentation
<term><option>--start=<replaceable>start</replaceable></option></term>
<listitem>
<para>
Log position at which to start reading. The default is to start reading
WAL location at which to start reading. The default is to start reading
the first valid log record found in the earliest file found.
</para>
</listitem>

2
doc/src/sgml/wal.sgml
View File

@ -791,7 +791,7 @@
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
scanning forward from the log position indicated in the checkpoint
scanning forward from the log location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
log on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"> is not disabled), all pages