On Wed, Apr 20, 2011 at 7:42 AM, Greg Stark <gsstark@mit.edu> wrote:
> On Wed, Apr 20, 2011 at 12:24 PM, Greg Stark <gsstark@mit.edu> wrote:
>> I haven't read the patch but are you delaying delivering the log or
>> delaying replaying it? I think you actually want the latter so in case
>> of a real failure you can choose between replaying the last 5 minutes
>> and recovering everything or intentionally dropping that history if
>> the failure was caused by an application problem.
>>
>
> Ok, so I read the patch. That wasn't so hard.
>
> You did implement it the way I described so great.
>
> However you did it by comparing the server timestamp and the slave
> timestamp. I think we should avoid that. Synchronizing clocks is a
> surprisingly hard problem and it would really be great if the whole
> system kept working if the clocks were out of sync.
>
> I don't think that's impossible, though it's a bit inconvenient. We
> would need to keep track of the most recent timestamp received from
> the master and pause recovery if we reach recovery on a record that's
> less than five minutes older than that record. This means we're
> comparing only master timestamps to each other. It does mean if the
> log transfer lags then recovery will lag unnecessarily. And it means
> the process of receiving logs is complicated by having to keep track
> of this timestamp.
How would we keep track of the most recent timestamp received from the
master without replaying the WAL records?
What happens if the connection to the master is lost?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company