Too many WAL archive files

My company is using PostgreSQL 9.1 for one of our applications. We have it set up replicating between two sites using WAL and Pacemaker to manage the cluster and failover. I have noticed that archive folder is growing very large 16G out of the 19G that the data directory is in total. We have the wal_keep_segments = 1000 set in the postgresql.conf file.

I thought that meant to keep the last 1000 files in the event that it was needed to catch up after falling behind. I am noticing that I have 12000 files in the archive directory. I know that includes the .backup files as well, but that is a smaller portion of the files in that directory.

Is there something that I am missing? Below is the replication section of the configuration file, if that helps.

Any guidance would be greatly appreciated,

Keith

#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Master Server -

# These settings are ignored on a standby server

max_wal_senders = 2 # max number of walsender processes
# (change requires restart)
#wal_sender_delay = 1s # walsender cycle time, 1-10000 milliseconds
wal_keep_segments = 1000 # in logfile segments, 16MB each; 0 disables
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
#replication_timeout = 60s # in milliseconds; 0 disables
#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all

# - Standby Servers -

# These settings are ignored on a master server

hot_standby = on # "on" allows queries during recovery
# (change requires restart)
max_standby_archive_delay = -1 # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
max_standby_streaming_delay = -1 # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
wal_receiver_status_interval = 2s # send replies at least this often
# 0 disables
hot_standby_feedback = on # send info from standby to prevent
# query conflicts