Re: Synch Rep v5

On Sun, 2009-01-11 at 17:19 +0900, Fujii Masao wrote:

> Thanks for your comments!
>
> On Sat, Jan 10, 2009 at 10:36 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > I notice we use the same settings for keepalives. We may need that to be
> > a second set of parameters.
>
> Or, we should make walreceiver execute "SET tcp_keepalives_xxx TO yyy"
> before starting replication if such settins are specified in recovery.conf?

Sounds reasonable, if maybe not ideal.

> > Don't understand: "Completely automated catching up; User has to carry
> > out some procedure manually for making the standby catch up."
>
> Oh sorry, this description is not correct; the standby can catch up with the
> primary automatically if archive area is shared between those two servers.
> In fact, xlogs generated before / during replication are shipped by
> archiver / walsender, respectively.
>
> I also updated the figures about flow of xlogs. Please check it.
> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Architecture_Design

Can't see anything different!

> > 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.

> > 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.

> > 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.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support