From c1a7f64b4a720a662ecec809bc9e289f35e887ad Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 12 May 2017 11:49:56 -0400 Subject: Replace "transaction log" with "write-ahead log" This makes documentation and error messages match the renaming of "xlog" to "wal" in APIs and file naming. --- doc/src/sgml/backup.sgml | 2 +- doc/src/sgml/config.sgml | 2 +- doc/src/sgml/func.sgml | 64 ++++++++++++++++++------------------- doc/src/sgml/high-availability.sgml | 6 ++-- doc/src/sgml/monitoring.sgml | 26 +++++++-------- doc/src/sgml/protocol.sgml | 2 +- doc/src/sgml/recovery-config.sgml | 2 +- doc/src/sgml/ref/checkpoint.sgml | 4 +-- doc/src/sgml/ref/initdb.sgml | 2 +- doc/src/sgml/ref/pg_basebackup.sgml | 32 +++++++++---------- doc/src/sgml/ref/pg_receivewal.sgml | 16 +++++----- doc/src/sgml/ref/pgbench.sgml | 2 +- doc/src/sgml/ref/pgtestfsync.sgml | 2 +- doc/src/sgml/release-10.sgml | 2 +- 14 files changed, 82 insertions(+), 82 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 8cf63e478a0..7820de931cf 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1424,7 +1424,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' As with base backups, the easiest way to produce a standalone hot backup is to use the tool. If you include the -X parameter when calling - it, all the transaction log required to use the backup will be + it, all the write-ahead log required to use the backup will be included in the backup automatically, and no special action is required to restore the backup. diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 20bc3c61b12..e297166bd9b 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -3312,7 +3312,7 @@ ANY num_sync ( pg_stat_replication view. The standby will report - the last transaction log position it has written, the last position it + the last write-ahead log position 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 diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index e462fdcd595..0527641b7cc 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -18466,21 +18466,21 @@ SELECT set_config('log_statement_stats', 'off', false); pg_current_wal_flush_lsn() pg_lsn - Get current transaction log flush location + Get current write-ahead log flush location pg_current_wal_insert_lsn() pg_lsn - Get current transaction log insert location + Get current write-ahead log insert location pg_current_wal_lsn() pg_lsn - Get current transaction log write location + Get current write-ahead log write location @@ -18522,28 +18522,28 @@ SELECT set_config('log_statement_stats', 'off', false); pg_switch_wal() pg_lsn - Force switch to a new transaction log file (restricted to superusers by default, but other users can be granted EXECUTE to run the function) + Force switch to a new write-ahead log file (restricted to superusers by default, but other users can be granted EXECUTE to run the function) pg_walfile_name(lsn pg_lsn) text - Convert transaction log location to file name + Convert write-ahead log location to file name pg_walfile_name_offset(lsn pg_lsn) text, integer - Convert transaction log location to file name and decimal byte offset within file + Convert write-ahead log location to file name and decimal byte offset within file pg_wal_lsn_diff(lsn pg_lsn, lsn pg_lsn) numeric - Calculate the difference between two transaction log locations + Calculate the difference between two write-ahead log locations @@ -18556,7 +18556,7 @@ SELECT set_config('log_statement_stats', 'off', false); backup label file (backup_label) and, if there are any links in the pg_tblspc/ directory, a tablespace map file (tablespace_map) into the database cluster's data directory, - performs a checkpoint, and then returns the backup's starting transaction + performs a checkpoint, and then returns the backup's starting write-ahead log location as text. The user can ignore this result value, but it is provided in case it is useful. When used in non-exclusive mode, the contents of these files are instead returned by the @@ -18592,30 +18592,30 @@ postgres=# select pg_start_backup('label_goes_here'); - The function also creates a backup history file in the transaction log + The function also creates a backup history file in the write-ahead log archive area. The history file includes the label given to - pg_start_backup, the starting and ending transaction log locations for + pg_start_backup, the starting and ending write-ahead log locations for the backup, and the starting and ending times of the backup. The return - value is the backup's ending transaction log location (which again + value is the backup's ending write-ahead log location (which again can be ignored). After recording the ending location, the current - transaction log insertion - point is automatically advanced to the next transaction log file, so that the - ending transaction log file can be archived immediately to complete the backup. + write-ahead log insertion + point is automatically advanced to the next write-ahead log file, so that the + ending write-ahead log file can be archived immediately to complete the backup. - pg_switch_wal moves to the next transaction log file, allowing the + pg_switch_wal moves to the next write-ahead log file, allowing the current file to be archived (assuming you are using continuous archiving). - The return value is the ending transaction log location + 1 within the just-completed transaction log file. - If there has been no transaction log activity since the last transaction log switch, + The return value is the ending write-ahead log location + 1 within the just-completed write-ahead log file. + If there has been no write-ahead log activity since the last write-ahead log switch, pg_switch_wal does nothing and returns the start location - of the transaction log file currently in use. + of the write-ahead log file currently in use. - pg_create_restore_point creates a named transaction log + pg_create_restore_point creates a named write-ahead log record that can be used as recovery target, and returns the corresponding - transaction log location. The given name can then be used with + write-ahead log location. The given name can then be used with to specify the point up to which recovery will proceed. Avoid creating multiple restore points with the same name, since recovery will stop at the first one whose name matches @@ -18623,16 +18623,16 @@ postgres=# select pg_start_backup('label_goes_here'); - pg_current_wal_lsn displays the current transaction log write + pg_current_wal_lsn displays the current write-ahead log write location in the same format used by the above functions. Similarly, - pg_current_wal_insert_lsn displays the current transaction log + pg_current_wal_insert_lsn displays the current write-ahead log insertion location and pg_current_wal_flush_lsn displays the - current transaction log flush location. The insertion location is the logical + current write-ahead log flush location. The insertion location is the logical end of the transaction log at any instant, while the write location is the end of what has actually been written out from the server's internal buffers and flush location is the location guaranteed to be written to durable storage. The write location is the end of what can be examined from outside the server, and is usually - what you want if you are interested in archiving partially-complete transaction log + what you want if you are interested in archiving partially-complete write-ahead log files. The insertion and flush locations are made available primarily for server debugging purposes. These are both read-only operations and do not require superuser permissions. @@ -18640,7 +18640,7 @@ postgres=# select pg_start_backup('label_goes_here'); You can use pg_walfile_name_offset to extract the - corresponding transaction log file name and byte offset from the results of any of the + corresponding write-ahead log file name and byte offset from the results of any of the above functions. For example: postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup()); @@ -18649,17 +18649,17 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup()); 00000001000000000000000D | 4039624 (1 row) - Similarly, pg_walfile_name extracts just the transaction log file name. - When the given transaction log location is exactly at a transaction log file boundary, both - these functions return the name of the preceding transaction log file. - This is usually the desired behavior for managing transaction log archiving + Similarly, pg_walfile_name extracts just the write-ahead log file name. + When the given write-ahead log location is exactly at a write-ahead log file boundary, both + these functions return the name of the preceding write-ahead log file. + This is usually the desired behavior for managing write-ahead log archiving behavior, since the preceding file is the last one that currently needs to be archived. pg_wal_lsn_diff calculates the difference in bytes - between two transaction log locations. It can be used with + between two write-ahead log locations. It can be used with pg_stat_replication or some functions shown in to get the replication lag. @@ -18716,7 +18716,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup()); pg_last_wal_receive_lsn() pg_lsn - Get last transaction log location received and synced to disk by + Get last write-ahead log location received and synced to disk by streaming replication. While streaming replication is in progress this will increase monotonically. If recovery has completed this will remain static at @@ -18730,7 +18730,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup()); pg_last_wal_replay_lsn() pg_lsn - Get last transaction log location replayed during recovery. + Get last write-ahead log location replayed during recovery. If recovery is still in progress this will increase monotonically. If recovery has completed then this value will remain static at the value of the last WAL record applied during that recovery. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 913f9ae41f5..92e3b454fbf 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -138,7 +138,7 @@ protocol to make nodes agree on a serializable transactional order. - Transaction Log Shipping + Write-Ahead Log Shipping @@ -289,7 +289,7 @@ protocol to make nodes agree on a serializable transactional order. Feature Shared Disk Failover File System Replication - Transaction Log Shipping + Write-Ahead Log Shipping Trigger-Based Master-Standby Replication Statement-Based Replication Middleware Asynchronous Multimaster Replication @@ -1036,7 +1036,7 @@ primary_slot_name = 'node_a_slot' When requesting synchronous replication, each commit of a write transaction will wait until confirmation is - received that the commit has been written to the transaction log on disk + received that the commit has been written to the write-ahead log on disk of both the primary and standby server. The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. This can provide a much higher level of durability, though only diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index d5e656f2db8..de61e640698 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -1032,7 +1032,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser CLogTruncationLock - Waiting to truncate the transaction log or waiting for transaction log truncation to finish. + Waiting to truncate the write-ahead log or waiting for write-ahead log truncation to finish. clog @@ -1701,24 +1701,24 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i sent_lsn pg_lsn - Last transaction log location sent on this connection + Last write-ahead log location sent on this connection write_lsn pg_lsn - Last transaction log location written to disk by this standby + Last write-ahead log location written to disk by this standby server flush_lsn pg_lsn - Last transaction log location flushed to disk by this standby + Last write-ahead log location flushed to disk by this standby server replay_lsn pg_lsn - Last transaction log location replayed into the database on this + Last write-ahead log location replayed into the database on this standby server @@ -1865,7 +1865,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i receive_start_lsn pg_lsn - First transaction log position used when WAL receiver is + First write-ahead log position used when WAL receiver is started @@ -1876,14 +1876,14 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i received_lsn pg_lsn - Last transaction log position already received and flushed to + Last write-ahead log position already received and flushed to disk, the initial value of this field being the first log position used when WAL receiver is started received_tli integer - Timeline number of last transaction log position received and + Timeline number of last write-ahead log position 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 @@ -1901,12 +1901,12 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i latest_end_lsn pg_lsn - Last transaction log position reported to origin WAL sender + Last write-ahead log position reported to origin WAL sender latest_end_time timestamp with time zone - Time of last transaction log position reported to origin WAL sender + Time of last write-ahead log position reported to origin WAL sender slot_name @@ -1967,7 +1967,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i received_lsn pg_lsn - Last transaction log position received, the initial value of + Last write-ahead log position received, the initial value of this field being 0 @@ -1984,13 +1984,13 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i latest_end_lsn pg_lsn - Last transaction log position reported to origin WAL sender + Last write-ahead log position reported to origin WAL sender latest_end_time timestamp with time zone - Time of last transaction log position reported to origin WAL + Time of last write-ahead log position reported to origin WAL sender diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index cb72c5d9dd7..dadaa47d697 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1547,7 +1547,7 @@ The commands accepted in walsender mode are: Current WAL flush location. Useful to get a known location in the - transaction log where streaming can start. + write-ahead log where streaming can start. diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml index a91864bf623..0a5d086248c 100644 --- a/doc/src/sgml/recovery-config.sgml +++ b/doc/src/sgml/recovery-config.sgml @@ -242,7 +242,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows - This parameter specifies the LSN of the transaction log location up + This parameter specifies the LSN of the write-ahead log location up to which recovery will proceed. The precise stopping point is also influenced by . This parameter is parsed using the system data type diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml index fa4dcc4f27d..a8f3186d8c0 100644 --- a/doc/src/sgml/ref/checkpoint.sgml +++ b/doc/src/sgml/ref/checkpoint.sgml @@ -13,7 +13,7 @@ CHECKPOINT - force a transaction log checkpoint + force a write-ahead log checkpoint @@ -26,7 +26,7 @@ CHECKPOINT Description - A checkpoint is a point in the transaction log sequence at which + A checkpoint is a point in the write-ahead log sequence at which all data files have been updated to reflect the information in the log. All data files will be flushed to disk. Refer to for more details about what happens diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml index d9faa96021d..3ce99e248b4 100644 --- a/doc/src/sgml/ref/initdb.sgml +++ b/doc/src/sgml/ref/initdb.sgml @@ -320,7 +320,7 @@ PostgreSQL documentation - This option specifies the directory where the transaction log + This option specifies the directory where the write-ahead log should be stored. diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml index e1cec9d60fa..2454d35af39 100644 --- a/doc/src/sgml/ref/pg_basebackup.sgml +++ b/doc/src/sgml/ref/pg_basebackup.sgml @@ -178,8 +178,8 @@ PostgreSQL documentation target directory, the tar contents will be written to standard output, suitable for piping to for example gzip. This is only possible if - the cluster has no additional tablespaces and transaction - log streaming is not used. + the cluster has no additional tablespaces and WAL + streaming is not used. @@ -299,9 +299,9 @@ PostgreSQL documentation - Specifies the location for the transaction log directory. + Specifies the location for the write-ahead log directory. waldir must be an absolute path. - The transaction log directory can only be specified when + The write-ahead log directory can only be specified when the backup is in plain mode. @@ -312,15 +312,15 @@ PostgreSQL documentation - Includes the required transaction log files (WAL files) in the - backup. This will include all transaction logs generated during + Includes the required write-ahead log files (WAL files) in the + backup. This will include all write-ahead logs generated during the backup. Unless the method none is specified, it is possible to start a postmaster directly in the extracted directory without the need to consult the log archive, thus making this a completely standalone backup. - The following methods for collecting the transaction logs are + The following methods for collecting the write-ahead logs are supported: @@ -329,7 +329,7 @@ PostgreSQL documentation none - Don't include transaction log in the backup. + Don't include write-ahead log in the backup. @@ -339,7 +339,7 @@ PostgreSQL documentation fetch - The transaction log files are collected at the end of the backup. + The write-ahead log files are collected at the end of the backup. Therefore, it is necessary for the parameter to be set high enough that the log is not removed before the end of the backup. @@ -347,7 +347,7 @@ PostgreSQL documentation backup will fail and be unusable. - The transaction log files will be written to + The write-ahead log files will be written to the base.tar file. @@ -358,16 +358,16 @@ PostgreSQL documentation stream - Stream the transaction log while the backup is created. This will + Stream the write-ahead log while the backup is created. This will open a second connection to the server and start streaming the - transaction log in parallel while running the backup. Therefore, + write-ahead log in parallel while running the backup. Therefore, it will use up two connections configured by the parameter. As long as the - client can keep up with transaction log received, using this mode - requires no extra transaction logs to be saved on the master. + client can keep up with write-ahead log received, using this mode + requires no extra write-ahead logs to be saved on the master. - The transaction log files are written to a separate file + The write-ahead log files are written to a separate file named pg_wal.tar (if the server is a version earlier than 10, the file will be named pg_xlog.tar). @@ -443,7 +443,7 @@ PostgreSQL documentation By default, when pg_basebackup aborts with an error, it removes any directories it might have created before discovering that it cannot finish the job (for example, data directory - and transaction log directory). This option inhibits tidying-up and is + and write-ahead log directory). This option inhibits tidying-up and is thus useful for debugging. diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml index 0e6b636703c..a17082bb11c 100644 --- a/doc/src/sgml/ref/pg_receivewal.sgml +++ b/doc/src/sgml/ref/pg_receivewal.sgml @@ -16,7 +16,7 @@ PostgreSQL documentation pg_receivewal - stream transaction logs from a PostgreSQL server + stream write-ahead logs from a PostgreSQL server @@ -31,8 +31,8 @@ PostgreSQL documentation Description - pg_receivewal is used to stream the transaction log - from a running PostgreSQL cluster. The transaction + pg_receivewal is used to stream the write-ahead log + from a running PostgreSQL cluster. The write-ahead log is streamed using the streaming replication protocol, and is written to a local directory of files. This directory can be used as the archive location for doing a restore using point-in-time recovery (see @@ -40,7 +40,7 @@ PostgreSQL documentation - pg_receivewal streams the transaction + pg_receivewal streams the write-ahead log in real time as it's being generated on the server, and does not wait for segments to complete like does. For this reason, it is not necessary to set @@ -56,7 +56,7 @@ PostgreSQL documentation - The transaction log is streamed over a regular + The write-ahead log is streamed over a regular PostgreSQL connection and uses the replication protocol. The connection must be made with a superuser or a user having REPLICATION permissions (see @@ -186,7 +186,7 @@ PostgreSQL documentation - Enables gzip compression of transaction logs, and specifies the + Enables gzip compression of write-ahead logs, and specifies the compression level (0 through 9, 0 being no compression and 9 being best compression). The suffix .gz will automatically be added to all filenames. @@ -366,7 +366,7 @@ PostgreSQL documentation When using pg_receivewal instead of as the main WAL backup method, it is strongly recommended to use replication slots. Otherwise, the server is - free to recycle or remove transaction log files before they are backed up, + free to recycle or remove write-ahead log files before they are backed up, because it does not have any information, either from or the replication slots, about how far the WAL stream has been archived. Note, however, that a @@ -380,7 +380,7 @@ PostgreSQL documentation Examples - To stream the transaction log from the server at + To stream the write-ahead log from the server at mydbserver and store it in the local directory /usr/local/pgsql/archive: diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 1eee8dc5742..5735c48717f 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -614,7 +614,7 @@ pgbench options dbname - Set the filename prefix for the transaction log files created by + Set the filename prefix for the log files created by diff --git a/doc/src/sgml/ref/pgtestfsync.sgml b/doc/src/sgml/ref/pgtestfsync.sgml index 5856356b427..467d6e647a2 100644 --- a/doc/src/sgml/ref/pgtestfsync.sgml +++ b/doc/src/sgml/ref/pgtestfsync.sgml @@ -34,7 +34,7 @@ problem. However, differences shown by pg_test_fsync might not make any significant difference in real database throughput, especially since many database servers - are not speed-limited by their transaction logs. + are not speed-limited by their write-ahead logs. pg_test_fsync reports average file sync operation time in microseconds for each wal_sync_method, which can also be used to inform efforts to optimize the value of . diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml index 7758c52e1fc..402fdb44fa7 100644 --- a/doc/src/sgml/release-10.sgml +++ b/doc/src/sgml/release-10.sgml @@ -2517,7 +2517,7 @@ 2016-12-21 [ecbdc4c55] Forbid invalid combination of options in pg_basebackup. --> - Allow pg_basebackup to stream transaction log in + Allow pg_basebackup to stream write-ahead log in tar mode (Magnus Hagander) -- cgit v1.2.3