Re: Synch Rep v5 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Synch Rep v5
Date
Msg-id 3f0b79eb0901122339s73628442r3f59ac256d1a088d@mail.gmail.com
Whole thread Raw
In response to Re: Synch Rep v5  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Synch Rep v5  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Hi,

On Mon, Jan 12, 2009 at 1:10 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > Multiple standby is still possible, but just using old file based
>> > mechanisms. We would need to be careful about use of %R in that case.
>>
>> Yes. Synch Rep can work fine with existing warm-standby mechanism.
>
> If we want multiple standby servers they wouldn't both be able to trim
> files from the archive. So we would need to change pg_standby so it
> records the %R from multiple servers on the archive and only trimmed the
> max of those %R values.

s/max/min ?

>> > I believe the max delay is 2* wal_sender_delay.
>>
>> In async replication case, walsender tries to send the xlogs once per
>> wal_sender_delay, and receives the response from the standby on
>> demand. So, I think that max delay is wal_sender_delay. Am I missing
>> something?
>
> Sending takes time as well, so it is send_time + delay at least.

Right. I'll change the doc into an exact description.

Similarly, though the document of "synchronous_commit" says

-----------
When off, there can be a delay between when success is reported to
the client and when the transaction is really guaranteed to be safe
against a server crash. (The maximum delay is three times wal_writer_delay.)
-----------

write_time also should be added up to the maximum delay.


>> > I like the way recovery_trigger_file avoids changing pg_standby, but I
>> > guess we still need to plug that gap also one day. But does patch 10
>> > also have the other mechanism?
>>
>> As you imply, current synch-rep has already not needed the change
>> of pg_standby, so I'll get rid of the patch from synch-rep patchset.
>> Of course, this patch is still useful for existing warm-standby. I should
>> add this patch to commitfest for 8.5?
>
> May as well leave it in, so people can use it with 8.3.

I'd like this patch to be reviewed and committed for 8.4 even if synch-rep
is postponed to 8.5. Because this is very useful for existing warm-standby
mechanism, and only warm-standby would be still a built-in replication
solution in 8.4.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: "Fujii Masao"
Date:
Subject: Re: Recovery Test Framework
Next
From: Simon Riggs
Date:
Subject: Re: Synch Rep v5