From: | "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synch Rep v5 |
Date: | 2009-01-13 07:39:47 |
Message-ID: | 3f0b79eb0901122339s73628442r3f59ac256d1a088d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Mon, Jan 12, 2009 at 1:10 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-01-13 08:24:50 | Re: Recovery Test Framework |
Previous Message | Fujii Masao | 2009-01-13 07:12:44 | Re: Recovery Test Framework |