Eduardo Morras <emorrasg <at> yahoo.es> writes:
>
> On Wed, 06 Mar 2013 19:09:43 -0700
> CS DBA <cs_dba <at> consistentstate.com> wrote:
> > We actually are in HOT standby mode, and it is working. However we are
> > also migrating a second db from an older (8.4) server into this master
> > so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and
> > then restored it into our current 9.2 master
>
> I don't know, but maybe the dump from 8.4 to your master is one big
transaction that must be rolled by the
> slave. So the slave must store all wal files to be able to undo the big
dump transaction.
>
> --- ---
> Eduardo Morras <emorrasg <at> yahoo.es>
>
We have the same problem, when we drop a big schema
and import it again (with \i and autocommit on).
To use pg_basebackup with the option -x, we have
wal_keep_segments set to 32.
And we use pg_archive_cleanup_command:
archive_cleanup_command='/usr/lib/postgresql/9.2/bin/pg_archivecleanup
/var/lib/postgresql/9.2/main/pg_xlog %r'
But we get at least 118 WAL-Files.
In the past, we did not set ssl_renegotiation_limit=0
and the archive_command copied quickly so many
WAL-Files to pg_xlog, that the postgresql-database
stopped with no space left on device /var.
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/1018307
