In recent years,
recovery.conf has become more and more powerful. Back in the early days (which is before PostgreSQL 9.0), there was barely more than a restore_command and some recovery_target_time related setting. More modern versions of PostgreSQL offer a lot more already and give you the chance to control your replay process in a nice and professional way.
In this section, you will learn what kind of settings there are and how you can make use of those features easily.
Up to now, we have archived the XLOG indefinitely. Just like in real life, infinity is a concept causing trouble. As John Maynard Keynes has already stated in his famous book, The General Theory of Employment, Interest, and Money:
"In the long run, we are all dead."
What applies to Keynesian stimulus is equally true in case of XLOG archiving; you simply cannot keep doing forever. At some point, the XLOG has to be thrown away.
To make cleanup easy, you can put an archive_cleanup_command into recovery.conf. Just like most other commands, (for example, the restore_command), this is a generic shell script. The script you will put in here will be executed at every restart point. So, what is a restart point? Every time PostgreSQL switches from file-based replay to streaming-based replay, you are facing a restart point. In fact, starting streaming again is considered to be a restart point.
You can make PostgreSQL execute some cleanup routine (or anything else) as soon as the restart point is reached. It is easily possible to clean out the older XLOG or trigger some notifications.
The following script shows how you can clean out any XLOG that is older than a day:
#!/bin/sh
find /archive -mtime +1 -exec rm -f {} ;Keep in mind that your script can be of any kind of complexity. You have to decide on a proper policy to handle the XLOG. Every business case is different and you have all the flexibility to control your archives and replication behavior.