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
From: Matheus de Oliveira [matioli.matheus@xxxxxxxxx]
Sent: Saturday, September 14, 2013 11:55 AM To: Keith Ouellette Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: Too many WAL archive files On Sat, Sep 14, 2013 at 11:19 AM, Keith Ouellette
<Keith.Ouellette@xxxxxxxxxx> wrote:
Matheus de Oliveira
No. PostgreSQL will always keep at least (can be a little more) wal_keep_segments files in any situation. So, wal_keep_segments is set to 1000, and each wal file has 16MB, doing the math it means PostgreSQL will use at least 15.625GB (~16GB) for wal files,
it is what you have. If you don't have enough space for this, you should set keep wal_keep_segments to a lower value.
Unless you have a lot of .backup files, there is no way 12000 wal file will use only 16GB, it would be 187.5GB, so this number seems wrong.
Also check if you have set up archiving and if it is working, because if archive_command fails, PostgreSQL will keep the "failed on archive" files on pg_xlog path and keep trying it.
Best regards,
--
Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres |