PostgreSQL replicas never finish recovering. This is by design. Basically a replica is always in "recovering from disaster" mode except that it is using receiving the WAL segments from the master rather than on disk.
So what you are seeing is not cause for concern. If it is not working yet, then you will need to provide a more detailed description of what you are trying to do and what is not working. But as far as you are posting it seems normal.
This seems to be fundamentally a question about Commvault Simpana, not PostgreSQL. As Commvault seems to be commercial software, you might have the best luck contacting their support desk.
Expected Behaviour Because Simpana is performing the backup with
PostgreSQL native commands, I expect that when Simpana has completed a
full backup or a WAL backup, that the files in the
/pgsql-backup/archive/postgres1/ directory are deleted.
I don't know what "a WAL backup" means here. Is that a terminology specific to Simpana? Does it just mean that the WAL files in your original archive directory have been copied to some off-site storage?
Questions If I weren't using Simpana for the backup, who would (have
to) delete the *.mmmmmmmm.backup files in the WAL Archive directory?
The pg_archivecleanup command?
If you weren't using Simpana, then you would be using something else. We can't tell you what that something else would be--there are lots of choices. While pg_archivecleanup is one such method, it is starting to look pretty obsolete these days. If you only want to keep your WAL files long enough for them to be safely stored (or replayed) on a stand-by, you would now use "streaming replication", and thereby do away with log shipping altogether.
Or you could have a policy to permanently keep the first base backup ever taken (immediately after you initialized your empty database), and every WAL file archived since then, so that you can do point-in-time-recovery to anytime in the history of your database.
Why is there still a full WAL file in the Archive Log directory, when
it should have been deleted like all the other WAL files in the
Archive Log directory?
It looks to me like when Simpana decides to clean up the archive, instead of removing all WAL files older than the oldest one currently needed, it instead deletes the range of files starting with the one still needed last time it did a clean up, ending at the one just before the one currently needed.
If this is the case, then if a WAL file was archived by PostgreSQL right after you turned on archiving, but before Simpana had been activated (or before it had gotten its bearings) then that file will never be removed.
Why isn't there a 00000003000000370000007A.mmmmmmmm.backup file for
the still existing 00000003000000370000007A WAL file in the archive
log directory?
If no backup was initiated during the period that 00000003000000370000007A was the active WAL file, then there never would have been a 00000003000000370000007A.mmmmmmmm.backup file in the first place.
Best Answer
Postgres temporarily adds WAL segments beyond
max_wal_sizeto absorb peak transaction loads without forcing a checkpoint -- unlike Oracle.It removes unneeded WAL seqments to avoid using up the log file system unnecessarily.
There's always a trade-off between performance and resource (in this case log disk space) utilization, and different DBMSes use different approaches to addressing this issue. In this case PostgreSQL lets you find the balance that works best for you by allowing you to play with the values of
wal_keep_segments,max_wal_sizeandmin_wal_size.