On Wed, 30 Jul 2008, Rob Adams wrote:
Could someone please explain in layman's terms the implications of using a
checkpoint_timeout of ~1min as well? Is it a bad idea?
Lowering checkpoint_timeout makes checkpoints more frequent, causing the
database to go through WAL segments (at 16MB
Greg Smith wrote:
On Wed, 30 Jul 2008, Rob Adams wrote:
Could someone please explain in layman's terms the implications of
using a checkpoint_timeout of ~1min as well? Is it a bad idea?
Lowering checkpoint_timeout makes checkpoints more frequent, causing the
database to go through WAL
Hello,
If you just want to ship segments to a standby server on a timely basis,
the setting to tune should be archive_timeout, no?
just curious, how would the stand-by DB process the segments?
Regards,
Bohdan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Bohdan Linda wrote:
Hello,
If you just want to ship segments to a standby server on a timely basis,
the setting to tune should be archive_timeout, no?
just curious, how would the stand-by DB process the segments?
You mean this?
http://www.postgresql.org/docs/8.3/static/pgstandby.html
We want to use an archive_timeout of ~1min to minimize data loss in the
event of hardware failure (archive script includes external b/u).
archive_timeout only seems to work if it's = checkpoint_timeout.
Could someone please explain in layman's terms the implications of using
a
Rob Adams [EMAIL PROTECTED] writes:
archive_timeout only seems to work if it's = checkpoint_timeout.
Hmm, no, they should be pretty independent. Define seems to work
please?
One possible connection is that an xlog file switch will not actually
happen unless some xlog output has been generated
I was referring to this post:
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01361.php
The test database was completely idle. WAL files were only being
archived at the interval specified in checkpoint_timeout (I was using
the default value) -- archive_timeout didn't make them happen
