We have a situation where walmanager is being used to ship wal files between a master and a slave Postgres database. The slave machine has failed and has had to have been rebuilt. This has caused a lot of unconsumed wal files to build up on the master.
If a reboot is issued to the Postgres master, and there are 24 hours worth of unconsumed wal files hanging around, will the master be effected at all or will it start clean?
If the WAL shipping is working right, then the master will start clean.
This sounds like conventional, pre-9.0, warm-standby WAL shipping. Recall roughly how it works. The master goes about its business until the WAL reaches a certain (configurable) size threshold. When the WAL size threshold is met, the master begins a WAL checkpoint. As part of the checkpoint, the master fully synchronizes all WAL records up to the checkpoint onto persistent storage. In other words, everything prior to a committed WAL checkpoint is guaranteed to be on disk. After a checkpoint commit, the preceding WAL can be safely discarded.
Postgres does discard or recycle WAL files after each checkpoint. But, with warm-standby, it first ships a checkpointed WAL segment by calling the archive_command you've configured it with. It sounds like you're using SkyTools's script as your archive_command. archive_command copies the WAL segment from the master's private storage, $PGDATA/data/pg_xlog, to some neutral storage where the slave can later consume it. You are using some neutral directory to store WAL segments until the slave consumes them, right? Anyway, once archive_command returns zero to the master, the master assumes the WAL segment was successfully shipped and deletes or reuses the segment file left behind in $PGDATA/data/pg_xlog. The master never knows or cares what happens after that. The segment copy made by archive_command might be consumed by a slave, or not; the master isn't involved.
In other words, the master's control ends when the WAL segment is shipped. Therefore the master can't meddle with shipped but unconsumed WAL segments. That includes rebooting the master.
BUT: If your WAL shipping is broken, then all bets are off. Be certain that your archive_command has been working right and that the unconsumed WALs reside in a neutral directory outside both Postgres installations. The previous discussion also assumes you're doing a recommended warm-standby config like the PG team details in the manual.
This is also my favorite time to check on backups. Gives me the warm and fuzzies to see that I can still restore if something unexpected happens...