Re: Synch Rep v5

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

In response to

Responses

Browse pgsql-hackers by date

  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