Date: Tue, 2 Dec 2014 14:42:45 -0700 (MST)
From: David G Johnston <david.g.johnston@gmail.com>
To: pgsql-admin@postgresql.org
Message-ID: <1417556565281-5828990.post@n5.nabble.com>
In-Reply-To: <547E1A3D.8040502@gmail.com>
References: <547E1A3D.8040502@gmail.com>
Subject: Re: 9.2 documentation/configuration question
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Jay at Verizon wrote
> checkpoint_timeout = 5min #default

This impacts the primary machine only and ensures that regardless of the
lack of activity a crash will only need to REDO that last five minutes of
history since everything prior to that will already have been persisted to
the data files.


> archive_timeout=3600

This impacts how far, in time, the archive can be behind the master in a
low-volume situation.  This is because only complete (16MB) WAL files are
shipped.  In a low volume situation it may take several active
checkpoint_timeout periods (not to mention zero activity periods) to
generate enough data to fill up a single 16MB file.

In a low volume situation a single WAL will have multiple checkpoint
records.  In a high volume situation there will be many WAL files that have
no checkpoint records.  This later situation being the reason for the
"checkpoint_segments" parameter.

So the archive will never be more than 16MB behind the master but the
corresponding time period is unbounded in the absence of archive_timeout. 
The master will always be up-to-date but the amount of time needed for
recovery is bounded either by time or size - which ever one comes first.

David J.


--
View this message in context: http://postgresql.nabble.com/9-2-documentation-configuration-question-tp5828964p5828990.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin