Skip site navigation (1) Skip section navigation (2)

Streaming Replication: Checkpoint_segment and wal_keep_segments on standby

From: "Sander, Ingo (NSN - DE/Munich)" <ingo(dot)sander(at)nsn(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
Date: 2010-05-27 13:13:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
With the parameter checkpoint_segment and wal_keep_segments the max. number of wal segments are set. If now the max number is reached, 
(1) the segments are deleted/recycled 
or (2) if the time set by the checkpoint_timeout is over, a checkpoint is set and if possible a deletion/recycling is done. 
This is the mechanism on the active side of a db server. On the standby side however only unused tranferred segments will be deleted if the checkpoint_timeout mechanism (2) is executed.
Is this a correct behaviour or it is an error? 
I have observed (checkpoint_segment set to 3; wal_keep_segments set to 10 and checkpoint_timeout set to 30min) that in my stress test the disk usage on standby side is increased up to 2GB with xlog segments whereby on the active side only ~60MB xlog files are available (we have patched the xlog file size to 4MB). To prevent this one possibility is to decreace the checkpoint_timeout to a low value (30sec), however this had the disadvantage that a checkpoint is often executed on active side which can influence the performance. Another possibility is to have different postgresql.conf on active and on standby side, but this is not our preferred solution. 

Best Regards/mfG
Ingo Sander
Nokia Siemens Networks GmbH &Co. KG
NWS EP CP SVSS Platform Tech Support DE
St.-Martin-Str. 76
D-81541 M√ľnchen
*Tel.:  +49-89-515938390


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-05-27 13:22:27
Subject: Re: primary/secondary/master/slave/standby
Previous:From: Fujii MasaoDate: 2010-05-27 13:09:12
Subject: Re: Synchronization levels in SR

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group