On Wed, 2008-12-24 at 11:39 +0900, Fujii Masao wrote:
> > We might ask why pg_start_backup() needs to perform checkpoint though,
> > since you have remarked that is a problem also.
> >
> > The answer is that it doesn't really need to, we just need to be certain
> > that archiving has been running since whenever we choose as the start
> > time. So we could easily just use the last normal checkpoint time, as
> > long as we had some way of tracking the archiving.
> >
> > ISTM we can solve the checkpoint problem more easily and it would
> > potentially save much more time than "tuning rsync for Postgres", which
> > is what the other idea amounted to. So I do see a solution that is both
> > better and more quickly achievable for 8.4.
>
> Sounds good. I agree that pg_start_backup basically doesn't need
> checkpoint. But, for full_page_write == off, we probably cannot get
> rid of it. Even if full_page_write == on, since we cannot make out
> whether all indispensable full pages were written after last checkpoint,
> pg_start_backup must do checkpoint with "forcePageWrite = on".
Yes, OK. So I think it would only work when full_page_writes = on, and
has been on since last checkpoint. So two changes:
* We just need a boolean that starts at true every checkpoint and gets
set to false anytime someone resets full_page_writes or archive_command.
If the flag is set && full_page_writes = on then we skip the checkpoint
entirely and use the value from the last checkpoint.
* My "infra" patch also had a modified version of pg_start_backup() that
allowed you to specify IMMEDIATE checkpoint or not. Reworking that seems
a waste of time, and I want to listen to everybody else now and change
pg_start_backup() so it throws an IMMEDIATE CHECKPOINT and leave it
there.
Can you work on those also?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support