On Wed, April 14, 2010 08:23, Heikki Linnakangas wrote: > Erik Rijkers wrote: >> This replication test that was working well earlier (it ran daily), stopped >> working > > This is probably because of this change: > >> date: 2010/04/12 09:52:29; author: heikki; state: Exp; lines: +71 -23 >> Change the logic to decide when to delete old WAL segments, so that it >> doesn't take into account how far the WAL senders are. This way a hung >> WAL sender doesn't prevent old WAL segments from being recycled/removed >> in the primary, ultimately causing the disk to fill up. Instead add >> standby_keep_segments setting to control how many old WAL segments are >> kept in the primary. This also makes it more reliable to use streaming >> replication without WAL archiving, assuming that you set >> standby_keep_segments high enough. > > If you generate enough WAL records in the master that the standby can't > keep up, the primary will eventually delete a WAL segment that hasn't > been streamed to the standby yet, hence the "requested WAL segment > 000000010000000000000032 has already been removed" error.
ah, I hadn't seen that change, and setting standby_keep_segments to some higher value (I chose 10000 for now) prevents these errors. >It shouldn't > remove the segment before it's successfully archived, though, and your > logs show that the standby can't find that file in the archive either. > Is archiving set up properly? It wasn't really - I was archiving on the primary server, instead of copying to the standby server. I'll fix that, thanks. Btw, typo alert: documentation 18.5.4, subhead 'standby_keep_segments', says: 'replciation' for 'replication'. http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html#RUNTIME-CONFIG-REPLICATION thanks, Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
