Simplifying "standby mode"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Simplifying "standby mode"
Date: 2006-08-07 13:48:14
Message-ID: 20900.1154958494@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

I'm in process of reviewing the restartable-recovery patch,
http://archives.postgresql.org/pgsql-patches/2006-07/msg00356.php
and I'm wondering if we really need to invent a "standby mode" boolean
to get the right behavior. The problem I see with that flag is that
it'd be static over a run, whereas the behavior we want is dynamic.
It seems entirely likely that a slave will be started from a base backup
that isn't quite current, and will need to run through some archived WAL
segments quickly before it catches up to the master. So during the
catchup period we'd prefer that it not do restartpoints one-for-one
with the logged checkpoints, whereas after it's caught up, that's what
we want.

I'm thinking that we could instead track the actual elapsed time since
the last restartpoint, and do a restartpoint when we encounter a
checkpoint WAL record and the time since the last restartpoint is
at least X. I'd be inclined to just use checkpoint_timeout for X,
although perhaps there's an argument to be made for making it
separately settable.

Thoughts?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-08-07 13:54:44 Re: pg_upgrade (was: 8.2 features status)
Previous Message Pavel Stehule 2006-08-07 13:29:23 Re: proposal for 8.3: Simultaneous assignment for PL/pgSQL

Browse pgsql-patches by date

  From Date Subject
Next Message Zdenek Kotala 2006-08-07 15:28:53 Re: Allow commenting of variables in postgresql.conf to -
Previous Message Tom Lane 2006-08-07 13:09:37 Re: CSStorm occurred again by postgreSQL8.2