Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 49400FF6.6080703@enterprisedb.com
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Wed, 2008-12-10 at 14:39 +0200, Heikki Linnakangas wrote:
> 
>> For a solution that doesn't depend on the file-based log shipping, I 
>> think we'll need a way for the standby to request a certain starting 
>> point for the streaming when it connects. When the standby starts, it 
>> would first recover all the log segments it can obtain using 
>> recovery_command, and then connect to the primary and request to
>> start 
>> streaming from where recovery_command stopped.
> 
> That was already suggested and rejected because it introduces a
> potentially unacceptable delay in the start of synch replication - for
> large databases this could be hours. (I should add it was suggested by
> me and I now accept that it should be rejected.)

I don't understand that argument. If the standby is missing say 100 log 
files, it's not up-to-date with the primary until it has somehow 
obtained and replayed all those log file. It doesn't make any difference 
whether it obtains them over the wire via walreceiver, or via an 
archive. Until it has obtained and replayed all those files, it's not 
up-to-date, and a failover would lead to data loss.

Or did I misunderstand what "start of synch replication" means? Got a 
pointer to the previous discussion?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PostgreSQL 8.3.4 reproducible crash
Next
From: Heikki Linnakangas
Date:
Subject: Re: Sync Rep: First Thoughts on Code