Обсуждение: 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

Okay, I guess it makes sense that I am at 16GB based on your explanation below. I do not have a space constraint, so having 16GB is not the problem. The problem is that we have experienced connectivity issues in the past where replication would not startup. I would do a "manual" sync using rsync for the data directory. That includes the archive directory. I tried to exclude the archive directory, but when restarting PostgreSQL, I would get the archive missing errors in the startup log and PostgreSQL would not start. I guess I could reduce the number from 1000 (which looks like about 55 days with an average of 18 files being created each day) to a lower number. We picked 1000 as this is a new application for us and we did not know how fast the WAL files would fill.  If I do make that change, will the excess files be automatically deleted or do I have to do that manually?

Thanks,

Keith