The history file includes the label given to pg_start_backup, the starting and ending transaction log locations for the backup, and the starting and ending times of the backup.
#Postgresql xlog position archive
Pg_stop_backup removes the label file created by pg_start_backup, and creates a backup history file in the transaction log archive area. This forces an immediate checkpoint which will cause a spike in I/O operations, slowing any concurrently executing queries. If true, it specifies executing pg_start_backup as quickly as possible. There is an optional second parameter of type boolean. postgres=# select pg_start_backup('label_goes_here') The user can ignore this result value, but it is provided in case it is useful. (Typically this would be the name under which the backup dump file will be stored.) The function writes a backup label file ( backup_label) into the database cluster's data directory, performs a checkpoint, and then returns the backup's starting transaction log location as text. Pg_start_backup accepts an arbitrary user-defined label for the backup. Pg_xlog_location_diff( location pg_lsn, location pg_lsn)Ĭalculate the difference between two transaction log locations Pg_xlogfile_name_offset( location pg_lsn)Ĭonvert transaction log location string to file name and decimal byte offset within file Get start time of an on-line exclusive backup in progress.įorce switch to a new transaction log file (restricted to superusers)Ĭonvert transaction log location string to file name True if an on-line exclusive backup is still in progress. Prepare for performing on-line backup (restricted to superusers or replication roles)įinish performing on-line backup (restricted to superusers or replication roles) Get current transaction log write location Get current transaction log insert location Backup Control Functions NameĬreate a named point for performing restore (restricted to superusers) This works only when the built-in log collector is running, since otherwise there is no log-file manager subprocess. Pg_rotate_logfile signals the log-file manager to switch to a new output file immediately. Pg_reload_conf sends a SIGHUP signal to the server, causing configuration files to be reloaded by all server processes. The role of an active backend can be found from the usename column of the pg_stat_activity view. The process ID of an active backend can be found from the pid column of the pg_stat_activity view, or by listing the postgres processes on the server (using ps on Unix or the Task Manager on Windows). Pg_cancel_backend and pg_terminate_backend send signals ( SIGINT or SIGTERM respectively) to backend processes identified by process ID. In all other cases, you must be a superuser.Įach of these functions returns true if successful and false otherwise. You can execute this against another backend that has exactly the same role as the user calling the function.
In all other cases, you must be a superuser.Ĭause server processes to reload their configuration files Server Signaling Functions NameĬancel a backend's current query. That may take a long time if your system suddenly becomes less active.Table 9-64.
This saves the disk some I/O, especially on busy systems.īear in mind that once a particular file has been recycled, it will not be reconsidered for removal/recycle again until it has been used (i.e., the relevant LSN is reached and checkpointed). So, as per your observation, you are probably observing the "recycle" effect - the old WAL files are getting renamed instead of getting removed.
Below that limit, the system recycles enough WAL files to cover the estimated need until the next checkpoint, and removes the rest If, due to a short-term peak of log output rate, max_wal_size is exceeded, the unneeded segment files will be removed until the system gets back under this limit. When old log segment files are no longer needed, they are removed or recycled (that is, renamed to become future segments in the numbered sequence). The number of WAL segment files in pg_xlog directory depends on min_wal_size, max_wal_size and the amount of WAL generated in previous checkpoint cycles. As per the documentation (emphasis added):
0 kommentar(er)
