Before we dive into the actual replay process, it makes sense to actually check archiving to make sure that it is working perfectly and as expected by using a simple ls command, as shown in the following code:

[hs@zenbook archive]$ ls -l 
total 212996 
-rw------- 1 hs hs 16777216 Jan 30 09:04 000000010000000000000001 
-rw------- 1 hs hs 16777216 Jan 30 09:04 000000010000000000000002 
-rw------- 1 hs hs 302      Jan 30 09:04 000000010000000000000002.00000028.backup 
-rw------- 1 hs hs 16777216 Jan 30 09:20 000000010000000000000003 
-rw------- 1 hs hs 16777216 Jan 30 09:20 000000010000000000000004 
-rw------- 1 hs hs 16777216 Jan 30 09:20 000000010000000000000005 
-rw------- 1 hs hs 16777216 Jan 30 09:20 000000010000000000000006 
... 

As soon as there is serious activity in the database, WAL files should be sent to the archive.

In addition to just checking for files, the following view can be useful:

test=# d pg_stat_archiver
              View "pg_catalog.pg_stat_archiver"
 Column             |         Type             | Modifiers
--------------------+--------------------------+-----------
 archived_count     | bigint                   | 
 last_archived_wal  | text                     |
 last_archived_time | timestamp with time zone |     
 failed_count       | bigint                   |
 last_failed_wal    | text                     | 
 last_failed_time   | timestamp with time zone |
 stats_reset        | timestamp with time zone |

The pg_stat_archiver system view is very useful for figuring out if and when archiving has stalled for whatever reason. It will tell us about the number of files already archived (archived_count). We can also see which file was the last one and when the event happened. Finally, the pg_stat_archiver system view can tell us when archiving has gone wrong, which is vital information. Unfortunately, the error code or the error message is not shown in the table, but since archive_command can be an arbitrary command, it is easy to log.

There is one more thing to see in the archive. As we described previously, it is important to see that those files are actually archived. But there's more. When the pg_basebackup command-line tool is called, we will see a .backup file in the stream of WAL files. It is small and contains only some information about the base backup itself—it is purely informative and is not needed by the replay process. However, it gives us some vital clues. When we start to replay the transaction log later on, we can delete all WAL files that are older than the .backup file. In this case, our backup file is called 000000010000000000000002.00000028.backup. This means that the replay process starts somewhere within file ...0002 (at position ...28). It also means that we can delete all files older than ...0002. Older WAL files won't be needed for recovery anymore. Keep in mind that we can keep more than just one backup around, so I am only referring to the current backup.

Now that archiving works, we can turn our attention to the replay process.