Re: Sync Rep: First Thoughts on Code

Hi,

On Wed, Dec 3, 2008 at 11:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> I'm patient, I know it takes time. Happy to spend hours on the review,
> but I want to do that knowing I agree with the higher level features and
> architecture first.

I wrote the features and restrictions of Synch Rep. Please also check
it together with the figures of architecture.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#User_Overview

> Some questions to check my understanding (expected answers in brackets)
>
> * Diagram on p.2 has two Archives. We have just one (yes)

No, we need archive in both the primary and standby. The primary needs
archive because a base backup is required when starting the standby.
Meanwhile, the standby needs archive for cooperating with pg_standby.

If the directory where pg_standby checks is the same as the directory
where walreceiver writes the WAL, the halfway WAL file might be
restored by pg_standby, and continuous recovery would fail. So, we have
to separate the directories, and I assigned pg_xlog and archive to them.

Another idea; walreceiver writes the WAL to the file with temporary name,
and rename it to the formal name when it fills. So, pg_standby doesn't
restore a halfway WAL file. But it's more difficult to perform the failover
because the unrenamed WAL file remains.

Do you have any other good idea?

>
> * We send data continuously, whether or not we are in sync/async? (yes)

Yes.

> So the only difference between sync/async is whether we wait when we
> flush the commit? (yes)

Yes.
And, in asynch case, the backend basically doesn't send the wakeup-signal
to walsender.

>
> * If we have synchronous_commit = off do we ignore
> synchronous_replication = on (yes)

No, we can configure them independently. synchronous_commit covers
only local writing of the WAL. If synch_*commit* should cover both local
writing and replication, I'd like to add new GUC which covers only local
writing (synchronous_local_write?).

>
> * If two transactions commit almost simultaneously and one is sync and
> the other async then only the sync backend will wait? (Yes)

Yes.

>
>
> Do we definitely need the archiver to move the files written by
> walreceiver to archive and then move them back out again?

Yes, it's because of cooperating with pg_standby.

> Seems like we
> can streamline that part in many (all?) cases.

Agreed. But I thought that such streaming was TODO of next time.

Regards,

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