Write Ahead Log

<p>wal_level determines how much information is written to the WAL. The default value is replica, which writes enough data to support WAL archiving and replication, including running read-only queries on a standby server. minimal removes all logging except the information required to recover from a crash or immediate shutdown. Finally, logical adds information necessary to support logical decoding. Each level includes the information logged at all lower levels. This parameter can only be set at server start.</p><p>In minimal level, no information is logged for permanent relations for the remainder of a transaction that creates or rewrites them. This can make operations much faster (see populate-pitr). Operations that initiate this optimization include: <ul class="simplelist"><li class="member">ALTER … SET TABLESPACE</li><li class="member">CLUSTER</li><li class="member">CREATE TABLE</li><li class="member">REFRESH MATERIALIZED VIEW (without CONCURRENTLY)</li><li class="member">REINDEX</li><li class="member">TRUNCATE</li></ul> But minimal WAL does not contain enough information to reconstruct the data from a base backup and the WAL logs, so replica or higher must be used to enable WAL archiving (archive_mode) and streaming replication.</p><p>In logical level, the same information is logged as with replica, plus information needed to allow extracting logical change sets from the WAL. Using a level of logical will increase the WAL volume, particularly if many tables are configured for REPLICA IDENTITY FULL and many UPDATE and DELETE statements are executed.</p><p>In releases prior to 9.6, this parameter also allowed the values archive and hot_standby. These are still accepted but mapped to replica.</p>

Bu parametre WAL’a ne kadar bilgi yazılacağını belirler. Varsayılan değer replica‘dır.

- replica değeri bir standby sunucu üzerinde çalışan read-only sorgular dahil, WAL archiving ve replikasyon işlemleri için yeterli veriyi sağlar.

- minimal, bir çökme veya ani kapanma durumunda recover işlemleri için gereken bilgileri garantiye alır. minimal değeri toplu veri operasyonlarıyla ilgili işlemleri (CREATE TABLE AS SELECT, CREATE INDEX) WAL günlüğüne kaydetmeyerek depolama avantajı sağlar.

- logical, logical decoding ve logical replication için gerekli bilgileri sağlar. logical seviyesi, replica seviyesinde kaydedilen bilgiler ek, WAL’dan mantıksal değişikliklerin ayıklanmasına olanak sağlamak için gerekli bilgileri günlüğe kaydeder. logical seviyesini kullanmak, özellikle birçok tablo REPLICA IDENTITY FULL olarak yapılandırılmışsa ve fazla UPDATE ve DELETE ifadesi yürütülüyorsa WAL hacmini artıracaktır.

Her düzey, alt düzeylerde kaydedilen tüm bilgileri içerir. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

<p>If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.</p><p>While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off fsync if you can easily recreate your entire database from external data.</p><p>Examples of safe circumstances for turning off fsync include the initial loading of a new database cluster from a backup file, using a database cluster for processing a batch of data after which the database will be thrown away and recreated, or for a read-only database clone which gets recreated frequently and is not used for failover. High quality hardware alone is not a sufficient justification for turning off fsync.</p><p>For reliable recovery when changing fsync off to on, it is necessary to force all modified buffers in the kernel to durable storage. This can be done while the cluster is shutdown or while fsync is on by running initdb –sync-only, running sync, unmounting the file system, or rebooting the server.</p><p>In many situations, turning off synchronous_commit for noncritical transactions can provide much of the potential performance benefit of turning off fsync, without the attendant risks of data corruption.</p><p>fsync can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.</p>

Güncellemelerin diske senkronizasyonunu zorlar. PostgreSQL sunucusu bu parametre açıksa, fsync () sistem çağrıları veya eşdeğer yöntemler ile değişikliklerin fiziksel olarak diske yazıldığından emin olmaya çalışır. Bu, veritabanı kümesinin bir işletim sistemi veya donanım çökmesinden sonra tutarlı bir duruma geri yüklenebilmesini sağlar.

fsync‘i kapatmak genellikle bir performans avantajı olmasına rağmen bir elektrik kesintisi veya sistem çökmesi durumunda kurtarılamaz veri bozulmasına neden olabilir.

fsync, yalnızca postgresql.conf dosyasından veya sunucu komut satırından ayarlanabilir. Bu parametreyi kapatdığınızda full_page_writes‘i de kapatmak düşünülebilir.

<p>Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a success indication to the client. Valid values are on, remote_apply, remote_write, local, and off. The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) Unlike fsync, setting this parameter to off does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning synchronous_commit off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see wal-async-commit.</p><p>If synchronous_standby_names is non-empty, this parameter also controls whether or not transaction commits will wait for their WAL records to be replicated to the standby server(s). When set to on, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to disk. This ensures the transaction will not be lost unless both the primary and all synchronous standbys suffer corruption of their database storage. When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s). When set to remote_write, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it out to their operating system. This setting is sufficient to ensure data preservation even if a standby instance of PostgreSQL were to crash, but not if the standby suffers an operating-system-level crash, since the data has not necessarily reached durable storage on the standby. Finally, the setting local causes commits to wait for local flush to disk, but not for replication. This is not usually desirable when synchronous replication is in use, but is provided for completeness.</p><p>If synchronous_standby_names is empty, the settings on, remote_apply, remote_write and local all provide the same synchronization level: transaction commits only wait for local flush to disk.</p><p>This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.</p>

Mevcut transaction’ın senkronizasyon seviyesini ayarlar. Veritabanı sunucusu istemciye bir ‘success’ işareti döndürmeden önce ne kadar WAL işlemenin tamamlanması gerektiğini belirtir. Geçerli değerleri remote_apply, on (varsayılan), remote_write, local ve off.

<p>Method used for forcing WAL updates out to disk. If fsync is off then this setting is irrelevant, since WAL file updates will not be forced out at all. Possible values are:</p><ul class="itemizedlist"><li class="listitem"><p>open_datasync (write WAL files with open() option O_DSYNC)</p></li><li class="listitem"><p>fdatasync (call fdatasync() at each commit)</p></li><li class="listitem"><p>fsync (call fsync() at each commit)</p></li><li class="listitem"><p>fsync_writethrough (call fsync() at each commit, forcing write-through of any disk write cache)</p></li><li class="listitem"><p>open_sync (write WAL files with open() option O_SYNC)</p></li></ul><p>The open_* options also use O_DIRECT if available. Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that fdatasync is the default on Linux. The default is not necessarily ideal; it might be necessary to change this setting or other aspects of your system configuration in order to create a crash-safe configuration or achieve optimal performance. These aspects are discussed in wal-reliability. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

WAL değişikliklerini diske göndermeye zorlamak için kullanılan yöntemi belirtir. fsync kapalıysa bu ayar geçersizdir. Olası değerler şunlardır: open_datasync, fdatasync, fsync, fsync_writethrough, open_sync. Verilen seçenekler tüm platformlarda mevcut değildir. fdatasync Linux’ta varsayılan değerdir. Bu parametre yalnızca postgresql.conf dosyasından veya sunucu komut satırından ayarlanabilir.

<p>When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at the price of increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.)</p><p>Turning this parameter off speeds normal operation, but might lead to either unrecoverable data corruption, or silent data corruption, after a system failure. The risks are similar to turning off fsync, though smaller, and it should be turned off only based on the same circumstances recommended for that parameter.</p><p>Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see continuous-archiving).</p><p>This parameter can only be set in the postgresql.conf file or on the server command line. The default is on.</p>

PostgreSQL sunucusu bu parametre açık olduğunda her bir disk page’inin tüm içeriğini, ilgili page’in checkpoint’den sonraki ilk değişikliğnde WAL’a yazar. Tüm page’in saklanması, page’in doğru bir şekilde geri yüklenmesini garanti eder ancak WAL’a yazılması gereken veri miktarını artırır. (WAL replay her zaman bir checkpoint’den başlar, bunu bir checkpoint’den sonra her sayfanın ilk değişikliği sırasında yapması yeterlidir. Bu nedenle, tüm page’i yazma maliyetini azaltmanın bir yolu, checkpoint aralığı parametrelerini artırmaktır.)

Bu parametrenin kapatılması çalışmayı hızlandırır ancak bir sistem arızasından sonra kurtarılamayan veri bozulmalarına neden olabilir.

Bu parametrenin kapatılması, point-in-time recovery (PITR) için WAL arşivleme kullanımını etkilemez.

Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir. Varsayılan açıktır.

<p>When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint, even for non-critical modifications of so-called hint bits.</p><p>If data checksums are enabled, hint bit updates are always WAL-logged and this setting is ignored. You can use this setting to test how much extra WAL-logging would occur if your database had data checksums enabled.</p><p>This parameter can only be set at server start. The default value is off.</p>

Bu parametre on değerinde PostgreSQL sunucusu, hint bits olarak bilinen kritik olmayan değişiklikler için bile bir checkpoint’den sonra ilgili page’in ilk değişikliğinde her disk page’inin tüm içeriğini WAL’a yazar. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir. Varsayılan değeri off‘dur.

<p>When this parameter is on, the PostgreSQL server compresses a full page image written to WAL when full_page_writes is on or during a base backup. A compressed page image will be decompressed during WAL replay. The default value is off. Only superusers can change this setting.</p><p>Turning this parameter on can reduce the WAL volume without increasing the risk of unrecoverable data corruption, but at the cost of some extra CPU spent on the compression during WAL logging and on the decompression during WAL replay.</p>

Bu parametre on değerinde PostgreSQL sunucusu WAL’a yazılan bir full page görüntüyü sıkıştırır. WAL replay sırasında sıkıştırılmış bir page görüntüsü açılacaktır. Varsayılan değer off‘dur. Bu ayarı yalnızca süper kullanıcılar değiştirebilir.

Bu parametrenin açılması kurtarılamaz veri bozulması riskini artırmaz, WAL boyutunu azaltır. Fakat, sıkıştırma ve WAL replay sırasında sıkıştırmanın açılmasından kaynaklı fazladan CPU harcanmasına neden olur.

<p>If set to on (the default), this option causes new WAL files to be filled with zeroes. On some file systems, this ensures that space is allocated before we need to write WAL records. However, Copy-On-Write (COW) file systems may not benefit from this technique, so the option is given to skip the unnecessary work. If set to off, only the final byte is written when the file is created so that it has the expected size.</p>

on ayarında (varsayılan), yeni WAL dosyaları ilk kullanımdan önce sıfır ile doldurulur. Böylece, bazı dosya sistemlerinde WAL kayıtları yazılmadan önce alanın tahsis edilmesi sağlanır.

<p>If set to on (the default), this option causes WAL files to be recycled by renaming them, avoiding the need to create new ones. On COW file systems, it may be faster to create new ones, so the option is given to disable this behavior.</p>

on ayarında (varsayılan), WAL dosyalarını yeniden adlandırarak geri kullanımını sağlar. Bu, yeni dosya oluşturma yükünden kurtarır. COW dosya sistemlerinde yenilerini oluşturmak daha hızlı olabildiğinden bu davranışı devre dışı bırakma seçeneği verilmiştir.

<p>The amount of shared memory used for WAL data that has not yet been written to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%) of shared_buffers, but not less than 64kB nor more than the size of one WAL segment, typically 16MB. This value can be set manually if the automatic choice is too large or too small, but any positive value less than 32kB will be treated as 32kB. If this value is specified without units, it is taken as WAL blocks, that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at server start.</p><p>The contents of the WAL buffers are written out to disk at every transaction commit, so extremely large values are unlikely to provide a significant benefit. However, setting this value to at least a few megabytes can improve write performance on a busy server where many clients are committing at once. The auto-tuning selected by the default setting of -1 should give reasonable results in most cases.</p>

Henüz diske yazılmamış WAL verileri için kullanılan shared memory miktarıdır. Öntanımlı -1 ayarı, shared_buffers’ın 1 / 32’ine eşit boyutu kullanır. Otomatik seçim çok büyük veya küçükse bu değer elle ayarlanabilir. 32kB’den küçük herhangi bir pozitif değer 32kB olarak değerlendirilecektir. Bu değer birim olmadan belirtildiğinde WAL blokları olarak alınır (XLOG_BLCKSZ bayt – 8kB). Öntanımlı -1 ayarı ile seçilen otomatik ayarlama çoğu durumda makul sonuçlar verir. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

<p>Specifies how often the WAL writer flushes WAL, in time terms. After flushing WAL the writer sleeps for the length of time given by wal_writer_delay, unless woken up sooner by an asynchronously committing transaction. If the last flush happened less than wal_writer_delay ago and less than wal_writer_flush_after worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting wal_writer_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

WAL writer’ın WAL’ı zaman cinsinden ne sıklıkla temizleyeceğini (flush) belirtir. WAL temizledikten sonra asenkron commit edilen bir transaction ile daha erken uyanmadıkça, WAL writer wal_writer_delay süresince uyur. Son temizleme, wal_writer_delay öncesinde gerçekleştiyse ve bu zamandan beri wal_writer_flush_after değerinden daha az WAL üretildiyse, WAL kayıtları yalnızca işletim sistemine yazılır, diske temizlenmez. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Varsayılan değer 200 milisaniyedir (200 ms). wal_writer_delay parametresini 10’un katı olmayan bir değere ayarlamak 10’un bir sonraki katına ayarlamakla aynı sonuçları verebilir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>Specifies how often the WAL writer flushes WAL, in volume terms. If the last flush happened less than wal_writer_delay ago and less than wal_writer_flush_after worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If wal_writer_flush_after is set to 0 then WAL data is always flushed immediately. If this value is specified without units, it is taken as WAL blocks, that is XLOG_BLCKSZ bytes, typically 8kB. The default is 1MB. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

WAL writer’ın volume cinsinden WAL’ı ne sıklıkla temizlediğini belirtir. Son temizleme, wal_writer_delay öncesinden gerçekleştiyse ve o zamandan beri wal_writer_flush_after değerinden daha az WAL üretildiyse, WAL yalnızca işletim sistemine yazılır, diske temizlenmez. wal_writer_flush_after 0 olarak ayarlanmışsa, WAL verileri anında temizlenir. Bu değer birim olmadan belirtilirse WAL blokları olarak alınır. (XLOG_BLCKSZ bayt – 8kB). Öntanımlı değeri 1MB’dir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>When wal_level is minimal and a transaction commits after creating or rewriting a permanent relation, this setting determines how to persist the new data. If the data is smaller than this setting, write it to the WAL log; otherwise, use an fsync of affected files. Depending on the properties of your storage, raising or lowering this value might help if such commits are slowing concurrent transactions. If this value is specified without units, it is taken as kilobytes. The default is two megabytes (2MB).</p>

wal_level = minimal olduğunda ve bir transaction kalıcı bir ilişki oluşturduktan ya da yeniden yazıldıktan sonra commit edildiğinde, bu ayar yeni verilerin nasıl kalıcı hale getirileceğini belirler. Veriler bu ayardan küçükse WAL log’larına yazılır, değilse fsync özelliği kullanılır. Depolamanızın özelliklerine bağlı olarak bu tür commitler eşzamanlı transaction’ları yavaşlatıyorsa bu değeri değiştirmek faydalı olabilir. Bu değer birimsiz belirtilirse kilobayt olarak alınır. Varsayılan, iki megabayttır (2MB).

<p>Setting commit_delay adds a time delay before a WAL flush is initiated. This can improve group commit throughput by allowing a larger number of transactions to commit via a single WAL flush, if system load is high enough that additional transactions become ready to commit within the given interval. However, it also increases latency by up to the commit_delay for each WAL flush. Because the delay is just wasted if no other transactions become ready to commit, a delay is only performed if at least commit_siblings other transactions are active when a flush is about to be initiated. Also, no delays are performed if fsync is disabled. If this value is specified without units, it is taken as microseconds. The default commit_delay is zero (no delay). Only superusers can change this setting.</p><p>In PostgreSQL releases prior to 9.3, commit_delay behaved differently and was much less effective: it affected only commits, rather than all WAL flushes, and waited for the entire configured delay even if the WAL flush was completed sooner. Beginning in PostgreSQL 9.3, the first process that becomes ready to flush waits for the configured interval, while subsequent processes wait only until the leader completes the flush operation.</p>

Bu parametrenin ayarlanması bir WAL temizliği başlatılmadan önce gecikme süresi ekler. Daha fazla sayıda transaction’ın tek bir WAL temizleme yoluyla commit edilmesini sağlayarak grup commit verimini artırır. fsync devre dışı bırakılırsa gecikme yapılmaz. Bu değer birimsiz belirtilirse, mikrosaniye olarak alınır. commit_delay öntanımlı değeri 0’dır (gecikme yok). Bu ayarı yalnızca süper kullanıcılar değiştirebilir.

<p>Minimum number of concurrent open transactions to require before performing the commit_delay delay. A larger value makes it more probable that at least one other transaction will become ready to commit during the delay interval. The default is five transactions.</p>

commit_delay’in gecikmeyi gerçekleştirmesi için gerekli minimum eşzamanlı açık transaction sayısını belirtir. Öntanımlı değeri 5 transaction’dır.

<p>Maximum time between automatic WAL checkpoints. If this value is specified without units, it is taken as seconds. The valid range is between 30 seconds and one day. The default is five minutes (5min). Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

Otomatik WAL checkpoint’leri arasında maksimum süreyi belirtir. Bu değer birimsiz belirtilirse, saniye olarak alınır. Geçerli aralık 30 saniye ile 1 gün arasındadır. Varsayılan değeri 5 dakikadır (5min). Bu parametrenin artırılması, crash recovery için gerekli süreyi artırabilir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>Specifies the target of checkpoint completion, as a fraction of total time between checkpoints. The default is 0.5. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

Total checkpoint süresinin bir bölümü olarak tamamlama hedefini belirtir. Öntanımlı değeri 0,5’tir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>Whenever more than this amount of data has been written while performing a checkpoint, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel’s page cache, reducing the likelihood of stalls when an fsync is issued at the end of the checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS’s page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 256kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.</p>

Bir checkpoint gerçekleştirilirken bu miktardan daha fazla veri yazıldığında, bunları işletim sistemi depolamasına yazmaya zorlar. Bazı platformlarda bu ayarın hiçbir etkisi olmayabilir. Bu değer birimsiz belirtilirse bloklar olarak alınır (BLCKSZ bayt – 8kB). Geçerli aralık zorunlu geri yazmayı devre dışı bırakan 0 ile 2MB arasıdır. Öntanımlı değeri Linux’ta 256kB, diğer sistemlerde 0’dır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>Write a message to the server log if checkpoints caused by the filling of WAL segment files happen closer together than this amount of time (which suggests that max_wal_size ought to be raised). If this value is specified without units, it is taken as seconds. The default is 30 seconds (30s). Zero disables the warning. No warnings will be generated if checkpoint_timeout is less than checkpoint_warning. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

checkpoint segmentleri bundan daha sık doldurulursa uyarıları etkinleştirir. Bu değer birimsiz belirtilirse saniye olarak alınır. Öntanımlı 30 saniyedir (30s). 0 uyarıyı devre dışı bırakır. checkpoint_timeout değeri checkpoint_warning‘den azsa hiçbir uyarı üretilmez. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>As long as WAL disk usage stays below this setting, old WAL files are always recycled for future use at a checkpoint, rather than removed. This can be used to ensure that enough WAL space is reserved to handle spikes in WAL usage, for example when running large batch jobs. If this value is specified without units, it is taken as megabytes. The default is 80 MB. This parameter can only be set in the postgresql.conf file or on the server command line.</p>

WAL disk kullanımı bu ayarın altında kaldığı sürece, eski WAL dosyalarını silmek yerine checkpoint’de tekrar kullanmak için geri dönüştürür. Bu değer birimsiz belirtilirse megabayt olarak alınır. Öntanımlı 80 MB’dir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>When archive_mode is enabled, completed WAL segments are sent to archive storage by setting archive_command. In addition to off, to disable, there are two modes: on, and always. During normal operation, there is no difference between the two modes, but when set to always the WAL archiver is enabled also during archive recovery or standby mode. In always mode, all files restored from the archive or streamed with streaming replication will be archived (again). See continuous-archiving-in-standby for details.</p><p>archive_mode and archive_command are separate variables so that archive_command can be changed without leaving archiving mode. This parameter can only be set at server start. archive_mode cannot be enabled when wal_level is set to minimal.</p>

Bu parametre etkinleştirildiğinde, tamamlanan WAL segmentleri archive_command ile arşiv depolamaya gönderilir. off, on ve always modları vardır. Normal çalışmada on ile always modu arasında fark yoktur. always ayarında archive recovery ve standby modunda da WAL arşivleyici etkinleştirilir. always modunda, arşivden geri yüklenen veya streaming replication ile akışa alınan tüm dosyalar arşivlenir.

<p>The local shell command to execute to archive a completed WAL file segment. Any %p in the string is replaced by the path name of the file to archive, and any %f is replaced by only the file name. (The path name is relative to the working directory of the server, i.e., the cluster’s data directory.) Use %% to embed an actual % character in the command. It is important for the command to return a zero exit status only if it succeeds. For more information see backup-archiving-wal.</p><p>This parameter can only be set in the postgresql.conf file or on the server command line. It is ignored unless archive_mode was enabled at server start. If archive_command is an empty string (the default) while archive_mode is enabled, WAL archiving is temporarily disabled, but the server continues to accumulate WAL segment files in the expectation that a command will soon be provided. Setting archive_command to a command that does nothing but return true, e.g., /bin/true (REM on Windows), effectively disables archiving, but also breaks the chain of WAL files needed for archive recovery, so it should only be used in unusual circumstances.</p>

Tamamlanmış bir WAL dosyası segmentini arşivlemek için çalıştırılacak kabuk komutudur. Değerdeki her %p arşivlenecek dosyanın path’i, her %f ise yalnızca dosya adıyla değiştirilir. path kümenin veri diziniyle ilişkilidir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

archive_command yalnızca tamamlanmış WAL segmentleri için çağrılır. Sunucunuz çok az WAL trafiği oluşturuyorsa bir transaction tamamlanması ile arşiv depolamasına gönderilmesi arasında gecikme olabilir. archive_timeout parametresi sunucuyu periyodik olarak yeni bir WAL segment dosyasına geçmeye zorlayacak şekilde ayarlanabilir. Bununla arşivlenmemiş verilerin ne kadar eski olabileceği sınırlandırılır. Zorunlu geçiş nedeniyle erken kapatılan arşivlenmiş dosyaların hala tamamen dolu dosyalarla aynı uzunlukta olduğuna dikkat edin. Bu nedenle, çok kısa archive_timeout kullanmak pek önerilmez. Bu arşiv depolama alanınızı şişirecektir. 1 dakikalık archive_timeout ayarları genellikle makuldur. Verilerin primary sunucudan daha hızlı kopyalanması isteniyorsa arşivleme yerine streaming replication kullanılabilir. Bu değer birimsiz belirtilirse saniye olarak alınır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

<p>The local shell command to execute to retrieve an archived segment of the WAL file series. This parameter is required for archive recovery, but optional for streaming replication. Any %f in the string is replaced by the name of the file to retrieve from the archive, and any %p is replaced by the copy destination path name on the server. (The path name is relative to the current working directory, i.e., the cluster’s data directory.) Any %r is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow a restore to be restartable, so this information can be used to truncate the archive to just the minimum required to support restarting from the current restore. %r is typically only used by warm-standby configurations (see warm-standby). Write %% to embed an actual % character.</p><p>It is important for the command to return a zero exit status only if it succeeds. The command will be asked for file names that are not present in the archive; it must return nonzero when so asked. Examples:restore_command = ‘cp /mnt/server/archivedir/%f “%p”‘restore_command = ‘copy “C:\server\archivedir\%f” “%p”’ # Windows An exception is that if the command was terminated by a signal (other than SIGTERM, which is used as part of a database server shutdown) or an error by the shell (such as command not found), then recovery will abort and the server will not start up.</p><p>This parameter can only be set at server start.</p>

WAL dosya serisinin arşivlenmiş bir bölümünü almak için yürütülecek kabuk komutudur. Bu parametre arşiv kurtarma için gereklidir, streaming replication için isteğe bağlıdır. Verilen string’teki her bir %f arşivden alınacak dosyanın adıyla, %p ise sunucudaki kopya hedef path adı ile değiştirilir. Path adı kümenin veri diziniyle ilişkilidir. Her bir %r geçerli son yeniden başlatma noktasını içeren dosyanın adıyla değiştirilir. %r genellikle warm-standby yapılandırmalarında kullanılır bkz. Komut başarılı olduğunda 0 exit status, arşivde bulunmayan dosyaları istediğinde 0 farklı bir değer döndürür. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

<p>This optional parameter specifies a shell command that will be executed at every restartpoint. The purpose of archive_cleanup_command is to provide a mechanism for cleaning up old archived WAL files that are no longer needed by the standby server. Any %r is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow a restore to be restartable, and so all files earlier than %r may be safely removed. This information can be used to truncate the archive to just the minimum required to support restart from the current restore. The pgarchivecleanup module is often used in archive_cleanup_command for single-standby configurations, for example:archive_cleanup_command = ‘pg_archivecleanup /mnt/server/archivedir %r’ Note however that if multiple standby servers are restoring from the same archive directory, you will need to ensure that you do not delete WAL files until they are no longer needed by any of the servers. archive_cleanup_command would typically be used in a warm-standby configuration (see warm-standby). Write %% to embed an actual % character in the command.</p><p>If the command returns a nonzero exit status then a warning log message will be written. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), a fatal error will be raised.</p><p>This parameter can only be set in the postgresql.conf file or on the server command line.</p>

İsteğe bağlı olan bu parametre, her restartpoint’de yürütülecek kabuk komutunu belirtir. archive_cleanup_command‘ın amacı artık standby sunucu tarafından ihtiyaç duyulmayan eski arşivlenmiş WAL dosyalarını temizlemek için bir mekanizma sağlamaktır. Her bir %r son geçerli restartpoint’i içeren dosyanın adıyla değiştirilir. Bu bilgiler, arşivi mevcut geri yüklemeden yeniden başlatmayı sağlamasında gereken minimum düzeye indirmek için kullanılır. pg_archivecleanup modülü genellikle archive_cleanup_command‘da single-standby konfigürasyonlar için kullanılır, örneğin:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

<p>This parameter specifies a shell command that will be executed once only at the end of recovery. This parameter is optional. The purpose of the recovery_end_command is to provide a mechanism for cleanup following replication or recovery. Any %r is replaced by the name of the file containing the last valid restart point, like in archive_cleanup_command.</p><p>If the command returns a nonzero exit status then a warning log message will be written and the database will proceed to start up anyway. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), the database will not proceed with startup.</p><p>This parameter can only be set in the postgresql.conf file or on the server command line.</p>

Bu parametre, recovery işleminin sonunda yalnızca bir kez yürütülecek bir kabuk komutunu belirtir. İsteğe bağlı bir parametredir. Amacı, replication ve recovery sonrasında temizleme için bir mekanizma sağlamaktır. Herbir %r, archive_cleanup_command‘da olduğu gibi geçerli en son yeniden başlatma noktasını içeren dosyanın adıyla değiştirilir.

Komut 0’dan farklı bir exit status döndürdüğünde log dosyasına bir uyarı mesajı yazılır ve veritabanı yine de başlatılır. Komutun bir sinyal veya kabuk tarafından bir hatayla sonlandırılması durumunda (komut bulunamadı gibi) veritabanı başlatmaya devam etmez.

Bu parametre yalnızca postgresql.conf dosyasında ve sunucu komut satırından ayarlanabilir.

<p>This parameter specifies that recovery should end as soon as a consistent state is reached, i.e., as early as possible. When restoring from an online backup, this means the point where taking the backup ended.</p><p>Technically, this is a string parameter, but 'immediate' is currently the only allowed value.</p>

Bu parametre, recovery işleminin tutarlı bir duruma ulaşılır ulaşılmaz, yani mümkün olan en kısa sürede bitmesi gerektiğini belirtir. ‘immediate’ şu anda izin verilen tek değerdir.

<p>This parameter specifies the named restore point (created with pg_create_restore_point()) to which recovery will proceed.</p>

Bu parametre, recovery işleminin devam edeceği adlandırılmış geri yükleme noktasını (pg_create_restore_point () ile oluşturulan) belirtir.

<p>This parameter specifies the time stamp up to which recovery will proceed. The precise stopping point is also influenced by guc-recovery-target-inclusive.</p><p>The value of this parameter is a time stamp in the same format accepted by the timestamp with time zone data type, except that you cannot use a time zone abbreviation (unless the timezone_abbreviations variable has been set earlier in the configuration file). Preferred style is to use a numeric offset from UTC, or you can write a full time zone name, e.g., Europe/Helsinki not EEST.</p>

Bu parametre, recovery işleminin devam edeceği zaman damgasını belirtir. Parametrenin değeri, timestamp with time zone veri tiple ile aynı formatta bir zaman damgasıdır, tek farkı bir saat dilimi kısaltması kullanılamaz (timezone_abbreviations değişkeni yapılandırma dosyasında ayarlanmadıkça). Tercih edilen stil UTC’den sayısal bir uzaklık kullanmaktır veya tam bir saat dilimi adı yazalabilir, örneğin, Europe/Istanbul.

<p>This parameter specifies the transaction ID up to which recovery will proceed. Keep in mind that while transaction IDs are assigned sequentially at transaction start, transactions can complete in a different numeric order. The transactions that will be recovered are those that committed before (and optionally including) the specified one. The precise stopping point is also influenced by guc-recovery-target-inclusive.</p>

Bu parametre, recovery işleminin devam edeceği transaction ID’sini belirtir. Transaction ID’leri transaction başlangıcında sıralı olarak atanmasına rağmen transaction’ların farklı sayısal sırada tamamlanabileceğine dikkat edin. Kurtarılacak transaction’lar, belirtilen transaction’dan önce yapılan commmit’dir.

<p>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 guc-recovery-target-inclusive. This parameter is parsed using the system data type pg_lsn.</p>

Bu parametre, recovery işleminin devam edeceği write-ahead log konumunun LSN’sini belirtir. Kesin durma noktası ayrıca recovery_target_inclusive’de bağlıdır. Bu parametre, pg_lsn sistem veri tipi kullanılarak parse edilir.