Re: [Skytools-users] WAL Shipping + checkpoint

From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Sébastien Lardière <slardiere(at)hi-media(dot)com>
Cc: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, skytools-users(at)pgfoundry(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [Skytools-users] WAL Shipping + checkpoint
Date: 2009-08-28 14:55:49
Message-ID: 4A97EFF5.3050503@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Sébastien Lardière wrote:
> No, i don't see any change in pg_controldata, but :
>
> there is messages in logfile :
>
> 2009-08-28 10:02:51,129 26717 INFO 00000001000003F700000088: Found
> 2009-08-28 10:02:51,169 26717 INFO {count: 1}
> 2009-08-28 10:02:51 CEST [18439]: [1862-1] user=,db= LOG: restored log
> file "00000001000003F700000088" from archive
>

This is weird, indeed it seems that for some reason the recovery restartpoints
are not created.

Looking quickly at RecoveryRestartPoint() in xlog.c, there are two cases when it
doesn't do a checkpoint. For one thing, it checks if if enough time has elapsed
since last controlfile modification. If not, the checkpoint is skipped. I'm wondering
if it does the correct thing if the clocks of two machines are too far apart.
Another check is "is it safe to do a checkpoint". This is logged with DEBUG2, so
it should be visible if you set the logging level accordingly.

Alternatively, you could attach a debugger to the recovery process and see if the
RecoveryRestartPoint() and CheckPointGuts() functions are called at all.

regards,
Martin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Karl Nack 2009-08-28 15:08:37 Work Scheduling DB Design
Previous Message Nathaniel Smith 2009-08-28 14:39:52 Re: Data audit trail techniques in postgresql