Skip to content

Commit d496a65

Browse files
peterepetere
committed
Standardize "WAL location" terminology
Other previously used terms were "WAL position" or "log position".
1 parent c1a7f64 commit d496a65

19 files changed

+62
-62
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3312,7 +3312,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
33123312
to the primary or upstream standby, where it can be seen using the
33133313
<link linkend="monitoring-stats-views-table">
33143314
<literal>pg_stat_replication</></link> view. The standby will report
3315-
the last write-ahead log position it has written, the last position it
3315+
the last write-ahead log location it has written, the last position it
33163316
has flushed to disk, and the last position it has applied.
33173317
This parameter's
33183318
value is the maximum interval, in seconds, between reports. Updates are

‎doc/src/sgml/datatype.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4635,7 +4635,7 @@ SELECT * FROM pg_attribute
46354635
standard comparison operators, like <literal>=</literal> and
46364636
<literal>&gt;</literal>. Two LSNs can be subtracted using the
46374637
<literal>-</literal> operator; the result is the number of bytes separating
4638-
those write-ahead log positions.
4638+
those write-ahead log locations.
46394639
</para>
46404640
</sect1>
46414641

‎doc/src/sgml/logicaldecoding.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -632,7 +632,7 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx,
632632
its XID. Note however that it can be NULL when the message is
633633
non-transactional and the XID was not assigned yet in the transaction
634634
which logged the message. The <parameter>lsn</parameter> has WAL
635-
position of the message. The <parameter>transactional</parameter> says
635+
location of the message. The <parameter>transactional</parameter> says
636636
if the message was sent as transactional or not.
637637
The <parameter>prefix</parameter> is arbitrary null-terminated prefix
638638
which can be used for identifying interesting messages for the current

‎doc/src/sgml/monitoring.sgml

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1829,7 +1829,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
18291829
being generated, but would differ when the sender becomes idle. In
18301830
particular, when the standby has caught up completely,
18311831
<structname>pg_stat_replication</structname> shows the time taken to
1832-
write, flush and replay the most recent reported WAL position rather than
1832+
write, flush and replay the most recent reported WAL location rather than
18331833
zero as some users might expect. This is consistent with the goal of
18341834
measuring synchronous commit and transaction visibility delays for
18351835
recent write transactions.
@@ -1865,7 +1865,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
18651865
<row>
18661866
<entry><structfield>receive_start_lsn</></entry>
18671867
<entry><type>pg_lsn</></entry>
1868-
<entry>First write-ahead log position used when WAL receiver is
1868+
<entry>First write-ahead log location used when WAL receiver is
18691869
started</entry>
18701870
</row>
18711871
<row>
@@ -1876,16 +1876,16 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
18761876
<row>
18771877
<entry><structfield>received_lsn</></entry>
18781878
<entry><type>pg_lsn</></entry>
1879-
<entry>Last write-ahead log position already received and flushed to
1880-
disk, the initial value of this field being the first log position used
1879+
<entry>Last write-ahead log location already received and flushed to
1880+
disk, the initial value of this field being the first log location used
18811881
when WAL receiver is started</entry>
18821882
</row>
18831883
<row>
18841884
<entry><structfield>received_tli</></entry>
18851885
<entry><type>integer</></entry>
1886-
<entry>Timeline number of last write-ahead log position received and
1886+
<entry>Timeline number of last write-ahead log location received and
18871887
flushed to disk, the initial value of this field being the timeline
1888-
number of the first log position used when WAL receiver is started
1888+
number of the first log location used when WAL receiver is started
18891889
</entry>
18901890
</row>
18911891
<row>
@@ -1901,12 +1901,12 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
19011901
<row>
19021902
<entry><structfield>latest_end_lsn</></entry>
19031903
<entry><type>pg_lsn</></entry>
1904-
<entry>Last write-ahead log position reported to origin WAL sender</entry>
1904+
<entry>Last write-ahead log location reported to origin WAL sender</entry>
19051905
</row>
19061906
<row>
19071907
<entry><structfield>latest_end_time</></entry>
19081908
<entry><type>timestamp with time zone</></entry>
1909-
<entry>Time of last write-ahead log position reported to origin WAL sender</entry>
1909+
<entry>Time of last write-ahead log location reported to origin WAL sender</entry>
19101910
</row>
19111911
<row>
19121912
<entry><structfield>slot_name</></entry>
@@ -1967,7 +1967,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
19671967
<row>
19681968
<entry><structfield>received_lsn</></entry>
19691969
<entry><type>pg_lsn</></entry>
1970-
<entry>Last write-ahead log position received, the initial value of
1970+
<entry>Last write-ahead log location received, the initial value of
19711971
this field being 0</entry>
19721972
</row>
19731973
<row>
@@ -1984,13 +1984,13 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
19841984
<row>
19851985
<entry><structfield>latest_end_lsn</></entry>
19861986
<entry><type>pg_lsn</></entry>
1987-
<entry>Last write-ahead log position reported to origin WAL sender
1987+
<entry>Last write-ahead log location reported to origin WAL sender
19881988
</entry>
19891989
</row>
19901990
<row>
19911991
<entry><structfield>latest_end_time</></entry>
19921992
<entry><type>timestamp with time zone</></entry>
1993-
<entry>Time of last write-ahead log position reported to origin WAL
1993+
<entry>Time of last write-ahead log location reported to origin WAL
19941994
sender</entry>
19951995
</row>
19961996
</tbody>

‎doc/src/sgml/protocol.sgml

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1724,7 +1724,7 @@ The commands accepted in walsender mode are:
17241724
<term><literal>consistent_point</literal> (<type>text</type>)</term>
17251725
<listitem>
17261726
<para>
1727-
The WAL position at which the slot became consistent. This is the
1727+
The WAL location at which the slot became consistent. This is the
17281728
earliest location from which streaming can start on this replication
17291729
slot.
17301730
</para>
@@ -1764,7 +1764,7 @@ The commands accepted in walsender mode are:
17641764
<listitem>
17651765
<para>
17661766
Instructs server to start streaming WAL, starting at
1767-
WAL position <replaceable class="parameter">XXX/XXX</>.
1767+
WAL location <replaceable class="parameter">XXX/XXX</>.
17681768
If <literal>TIMELINE</literal> option is specified,
17691769
streaming starts on timeline <replaceable class="parameter">tli</>;
17701770
otherwise, the server's current timeline is selected. The server can
@@ -1796,7 +1796,7 @@ The commands accepted in walsender mode are:
17961796
acknowledges this by also exiting COPY mode, the server sends a result
17971797
set with one row and two columns, indicating the next timeline in this
17981798
server's history. The first column is the next timeline's ID (type <type>int8</type>), and the
1799-
second column is the WAL position where the switch happened (type <type>text</type>). Usually,
1799+
second column is the WAL location where the switch happened (type <type>text</type>). Usually,
18001800
the switch position is the end of the WAL that was streamed, but there
18011801
are corner cases where the server can send some WAL from the old
18021802
timeline that it has not itself replayed before promoting. Finally, the
@@ -2115,7 +2115,7 @@ The commands accepted in walsender mode are:
21152115
<listitem>
21162116
<para>
21172117
Instructs server to start streaming WAL for logical replication, starting
2118-
at WAL position <replaceable class="parameter">XXX/XXX</>. The server can
2118+
at WAL location <replaceable class="parameter">XXX/XXX</>. The server can
21192119
reply with an error, for example if the requested section of WAL has already
21202120
been recycled. On success, server responds with a CopyBothResponse
21212121
message, and then starts to stream WAL to the frontend.
@@ -2147,7 +2147,7 @@ The commands accepted in walsender mode are:
21472147
<term><replaceable class="parameter">XXX/XXX</></term>
21482148
<listitem>
21492149
<para>
2150-
The WAL position to begin streaming at.
2150+
The WAL location to begin streaming at.
21512151
</para>
21522152
</listitem>
21532153
</varlistentry>

‎doc/src/sgml/ref/pg_waldump.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -85,7 +85,7 @@ PostgreSQL documentation
8585
<term><option>--end=<replaceable>end</replaceable></option></term>
8686
<listitem>
8787
<para>
88-
Stop reading at the specified log position, instead of reading to the
88+
Stop reading at the specified WAL location, instead of reading to the
8989
end of the log stream.
9090
</para>
9191
</listitem>
@@ -144,7 +144,7 @@ PostgreSQL documentation
144144
<term><option>--start=<replaceable>start</replaceable></option></term>
145145
<listitem>
146146
<para>
147-
Log position at which to start reading. The default is to start reading
147+
WAL location at which to start reading. The default is to start reading
148148
the first valid log record found in the earliest file found.
149149
</para>
150150
</listitem>

‎doc/src/sgml/wal.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -791,7 +791,7 @@
791791
<filename>pg_control</filename>. Therefore, at the start of recovery,
792792
the server first reads <filename>pg_control</filename> and
793793
then the checkpoint record; then it performs the REDO operation by
794-
scanning forward from the log position indicated in the checkpoint
794+
scanning forward from the log location indicated in the checkpoint
795795
record. Because the entire content of data pages is saved in the
796796
log on the first page modification after a checkpoint (assuming
797797
<xref linkend="guc-full-page-writes"> is not disabled), all pages

‎src/backend/access/transam/recovery.conf.sample

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,7 @@
6767
# must set a recovery target.
6868
#
6969
# You may set a recovery target either by transactionId, by name,
70-
# by timestamp or by WAL position (LSN). Recovery may either include or
70+
# by timestamp or by WAL location (LSN). Recovery may either include or
7171
# exclude the transaction(s) with the recovery target value (ie, stop either
7272
# just after or just before the given target, respectively).
7373
#

‎src/backend/access/transam/timeline.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515
* <parentTLI> <switchpoint> <reason>
1616
*
1717
* parentTLI ID of the parent timeline
18-
* switchpoint XLogRecPtr of the WAL position where the switch happened
18+
* switchpoint XLogRecPtr of the WAL location where the switch happened
1919
* reason human-readable explanation of why the timeline was changed
2020
*
2121
* The fields are separated by tabs. Lines beginning with # are comments, and
@@ -278,7 +278,7 @@ findNewestTimeLine(TimeLineID startTLI)
278278
*
279279
* newTLI: ID of the new timeline
280280
* parentTLI: ID of its immediate parent
281-
* switchpoint: XLOG position where the system switched to the new timeline
281+
* switchpoint: WAL location where the system switched to the new timeline
282282
* reason: human-readable explanation of why the timeline was switched
283283
*
284284
* Currently this is only used at the end recovery, and so there are no locking

‎src/backend/access/transam/twophase.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2294,7 +2294,7 @@ RecordTransactionAbortPrepared(TransactionId xid,
22942294
*
22952295
* Store pointers to the start/end of the WAL record along with the xid in
22962296
* a gxact entry in shared memory TwoPhaseState structure. If caller
2297-
* specifies InvalidXLogRecPtr as WAL position to fetch the two-phase
2297+
* specifies InvalidXLogRecPtr as WAL location to fetch the two-phase
22982298
* data, the entry is marked as located on disk.
22992299
*/
23002300
void

‎src/backend/access/transam/xlog.c

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5643,7 +5643,7 @@ recoveryStopsBefore(XLogReaderState *record)
56435643
recoveryStopTime = 0;
56445644
recoveryStopName[0] = '\0';
56455645
ereport(LOG,
5646-
(errmsg("recovery stopping before WAL position (LSN) \"%X/%X\"",
5646+
(errmsg("recovery stopping before WAL location (LSN) \"%X/%X\"",
56475647
(uint32) (recoveryStopLSN >> 32),
56485648
(uint32) recoveryStopLSN)));
56495649
return true;
@@ -5800,7 +5800,7 @@ recoveryStopsAfter(XLogReaderState *record)
58005800
recoveryStopTime = 0;
58015801
recoveryStopName[0] = '\0';
58025802
ereport(LOG,
5803-
(errmsg("recovery stopping after WAL position (LSN) \"%X/%X\"",
5803+
(errmsg("recovery stopping after WAL location (LSN) \"%X/%X\"",
58045804
(uint32) (recoveryStopLSN >> 32),
58055805
(uint32) recoveryStopLSN)));
58065806
return true;
@@ -6323,7 +6323,7 @@ StartupXLOG(void)
63236323
recoveryTargetName)));
63246324
else if (recoveryTarget == RECOVERY_TARGET_LSN)
63256325
ereport(LOG,
6326-
(errmsg("starting point-in-time recovery to WAL position (LSN) \"%X/%X\"",
6326+
(errmsg("starting point-in-time recovery to WAL location (LSN) \"%X/%X\"",
63276327
(uint32) (recoveryTargetLSN >> 32),
63286328
(uint32) recoveryTargetLSN)));
63296329
else if (recoveryTarget == RECOVERY_TARGET_IMMEDIATE)
@@ -7455,7 +7455,7 @@ StartupXLOG(void)
74557455
exitArchiveRecovery(EndOfLogTLI, EndOfLog);
74567456

74577457
/*
7458-
* Prepare to write WAL starting at EndOfLog position, and init xlog
7458+
* Prepare to write WAL starting at EndOfLog location, and init xlog
74597459
* buffer cache using the block containing the last record from the
74607460
* previous incarnation.
74617461
*/
@@ -10159,7 +10159,7 @@ XLogFileNameP(TimeLineID tli, XLogSegNo segno)
1015910159
* when backup needs to generate tablespace_map file, it is used to
1016010160
* embed escape character before newline character in tablespace path.
1016110161
*
10162-
* Returns the minimum WAL position that must be present to restore from this
10162+
* Returns the minimum WAL location that must be present to restore from this
1016310163
* backup, and the corresponding timeline ID in *starttli_p.
1016410164
*
1016510165
* Every successfully started non-exclusive backup must be stopped by calling
@@ -10669,7 +10669,7 @@ get_backup_status(void)
1066910669
* If labelfile is NULL, this stops an exclusive backup. Otherwise this stops
1067010670
* the non-exclusive backup specified by 'labelfile'.
1067110671
*
10672-
* Returns the last WAL position that must be present to restore from this
10672+
* Returns the last WAL location that must be present to restore from this
1067310673
* backup, and the corresponding timeline ID in *stoptli_p.
1067410674
*
1067510675
* It is the responsibility of the caller of this function to verify the
@@ -11569,7 +11569,7 @@ XLogPageRead(XLogReaderState *xlogreader, XLogRecPtr targetPagePtr, int reqLen,
1156911569
}
1157011570

1157111571
/*
11572-
* Open the WAL segment containing WAL position 'RecPtr'.
11572+
* Open the WAL segment containing WAL location 'RecPtr'.
1157311573
*
1157411574
* The segment can be fetched via restore_command, or via walreceiver having
1157511575
* streamed the record, or it can already be present in pg_wal. Checking

‎src/backend/replication/walreceiver.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1090,7 +1090,7 @@ XLogWalRcvFlush(bool dying)
10901090
}
10911091

10921092
/*
1093-
* Send reply message to primary, indicating our current XLOG positions, oldest
1093+
* Send reply message to primary, indicating our current WAL locations, oldest
10941094
* xmin and the current time.
10951095
*
10961096
* If 'force' is not set, the message is only sent if enough time has
@@ -1125,7 +1125,7 @@ XLogWalRcvSendReply(bool force, bool requestReply)
11251125
* We can compare the write and flush positions to the last message we
11261126
* sent without taking any lock, but the apply position requires a spin
11271127
* lock, so we don't check that unless something else has changed or 10
1128-
* seconds have passed. This means that the apply log position will
1128+
* seconds have passed. This means that the apply WAL location will
11291129
* appear, from the master's point of view, to lag slightly, but since
11301130
* this is only for reporting purposes and only on idle systems, that's
11311131
* probably OK.

‎src/backend/replication/walsender.c

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -194,7 +194,7 @@ static volatile sig_atomic_t replication_active = false;
194194
static LogicalDecodingContext *logical_decoding_ctx = NULL;
195195
static XLogRecPtr logical_startptr = InvalidXLogRecPtr;
196196

197-
/* A sample associating a log position with the time it was written. */
197+
/* A sample associating a WAL location with the time it was written. */
198198
typedef struct
199199
{
200200
XLogRecPtr lsn;
@@ -340,7 +340,7 @@ static void
340340
IdentifySystem(void)
341341
{
342342
char sysid[32];
343-
char xpos[MAXFNAMELEN];
343+
char xloc[MAXFNAMELEN];
344344
XLogRecPtr logptr;
345345
char *dbname = NULL;
346346
DestReceiver *dest;
@@ -367,7 +367,7 @@ IdentifySystem(void)
367367
else
368368
logptr = GetFlushRecPtr();
369369

370-
snprintf(xpos, sizeof(xpos), "%X/%X", (uint32) (logptr >> 32), (uint32) logptr);
370+
snprintf(xloc, sizeof(xloc), "%X/%X", (uint32) (logptr >> 32), (uint32) logptr);
371371

372372
if (MyDatabaseId != InvalidOid)
373373
{
@@ -406,8 +406,8 @@ IdentifySystem(void)
406406
/* column 2: timeline */
407407
values[1] = Int32GetDatum(ThisTimeLineID);
408408

409-
/* column 3: xlog position */
410-
values[2] = CStringGetTextDatum(xpos);
409+
/* column 3: wal location */
410+
values[2] = CStringGetTextDatum(xloc);
411411

412412
/* column 4: database name, or NULL if none */
413413
if (dbname)
@@ -842,7 +842,7 @@ static void
842842
CreateReplicationSlot(CreateReplicationSlotCmd *cmd)
843843
{
844844
const char *snapshot_name = NULL;
845-
char xpos[MAXFNAMELEN];
845+
char xloc[MAXFNAMELEN];
846846
char *slot_name;
847847
bool reserve_wal = false;
848848
CRSSnapshotAction snapshot_action = CRS_EXPORT_SNAPSHOT;
@@ -975,7 +975,7 @@ CreateReplicationSlot(CreateReplicationSlotCmd *cmd)
975975
ReplicationSlotSave();
976976
}
977977

978-
snprintf(xpos, sizeof(xpos), "%X/%X",
978+
snprintf(xloc, sizeof(xloc), "%X/%X",
979979
(uint32) (MyReplicationSlot->data.confirmed_flush >> 32),
980980
(uint32) MyReplicationSlot->data.confirmed_flush);
981981

@@ -1008,7 +1008,7 @@ CreateReplicationSlot(CreateReplicationSlotCmd *cmd)
10081008
values[0] = CStringGetTextDatum(slot_name);
10091009

10101010
/* consistent wal location */
1011-
values[1] = CStringGetTextDatum(xpos);
1011+
values[1] = CStringGetTextDatum(xloc);
10121012

10131013
/* snapshot name, or NULL if none */
10141014
if (snapshot_name != NULL)
@@ -1729,7 +1729,7 @@ PhysicalConfirmReceivedLocation(XLogRecPtr lsn)
17291729
}
17301730

17311731
/*
1732-
* Regular reply from standby advising of WAL positions on standby server.
1732+
* Regular reply from standby advising of WAL locations on standby server.
17331733
*/
17341734
static void
17351735
ProcessStandbyReplyMessage(void)
@@ -2579,7 +2579,7 @@ XLogSendPhysical(void)
25792579

25802580
/*
25812581
* Record the current system time as an approximation of the time at which
2582-
* this WAL position was written for the purposes of lag tracking.
2582+
* this WAL location was written for the purposes of lag tracking.
25832583
*
25842584
* In theory we could make XLogFlush() record a time in shmem whenever WAL
25852585
* is flushed and we could get that time as well as the LSN when we call
@@ -3353,7 +3353,7 @@ WalSndKeepaliveIfNecessary(TimestampTz now)
33533353

33543354
/*
33553355
* Record the end of the WAL and the time it was flushed locally, so that
3356-
* LagTrackerRead can compute the elapsed time (lag) when this WAL position is
3356+
* LagTrackerRead can compute the elapsed time (lag) when this WAL location is
33573357
* eventually reported to have been written, flushed and applied by the
33583358
* standby in a reply message.
33593359
*/
@@ -3410,7 +3410,7 @@ LagTrackerWrite(XLogRecPtr lsn, TimestampTz local_flush_time)
34103410
}
34113411

34123412
/*
3413-
* Find out how much time has elapsed between the moment WAL position 'lsn'
3413+
* Find out how much time has elapsed between the moment WAL location 'lsn'
34143414
* (or the highest known earlier LSN) was flushed locally and the time 'now'.
34153415
* We have a separate read head for each of the reported LSN locations we
34163416
* receive in replies from standby; 'head' controls which read head is

0 commit comments

Comments
 (0)