The archive callbacks define the actual archiving behavior of the module. The server will call them as required to process each individual WAL file.
The check_configured_cb callback is called to determine whether the module is fully configured and ready to accept WAL files (e.g., its configuration parameters are set to valid values). If no check_configured_cb is defined, the server always assumes the module is configured.
If true is returned, the server will proceed with archiving the file by calling the archive_file_cb callback. If false is returned, archiving will not proceed, and the archiver will emit the following message to the server log:
In the latter case, the server will periodically call this function, and archiving will proceed only when it returns true.
The archive_file_cb callback is called to archive a single WAL file.
If true is returned, the server proceeds as if the file was successfully archived, which may include recycling or removing the original WAL file. If false is returned, the server will keep the original WAL file and retry archiving later. file will contain just the file name of the WAL file to archive, while path contains the full path of the WAL file (including the file name).
The shutdown_cb callback is called when the archiver process exits (e.g., after an error) or the value of archive_library changes. If no shutdown_cb is defined, no special action is taken in these situations.
An archive library is loaded by dynamically loading a shared library with the archive_library's name as the library base name. The normal library search path is used to locate the library. To provide the required archive module callbacks and to indicate that the library is actually an archive module, it needs to provide a function named _PG_archive_module_init. This function is passed a struct that needs to be filled with the callback function pointers for individual actions.
Only the archive_file_cb callback is required. The others are optional.
PostgreSQL provides infrastructure to create custom modules for continuous archiving (see Section 26.3). While archiving via a shell command (i.e., archive_command) is much simpler, a custom archive module will often be considerably more robust and performant.
When a custom archive_library is configured, PostgreSQL will submit completed WAL files to the module, and the server will avoid recycling or removing these WAL files until the module indicates that the files were successfully archived. It is ultimately up to the module to decide what to do with each WAL file, but many recommendations are listed at Section 26.3.1.
Archiving modules must at least consist of an initialization function (see Section 51.1) and the required callbacks (see Section 51.2). However, archive modules are also permitted to do much more (e.g., declare GUCs and register background workers).
The contrib/basic_archive module contains a working example, which demonstrates some useful techniques.