Hi, On Wed, Dec 3, 2008 at 11:33 PM, Simon Riggs <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers