From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep: First Thoughts on Code |
Date: | 2008-12-03 14:33:00 |
Message-ID: | 1228314780.20796.475.camel@hp_dx2400_1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2008-12-03 at 21:37 +0900, Fujii Masao wrote:
> Since I thought that the figure was more intelligible for some people
> than my poor English, I illustrated the architecture first.
> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Detailed_Design
>
> Are there any other parts which should be illustrated for review?
Those are very useful, thanks.
Some questions to check my understanding (expected answers in brackets)
* Diagram on p.2 has two Archives. We have just one (yes)
* We send data continuously, whether or not we are in sync/async? (yes)
So the only difference between sync/async is whether we wait when we
flush the commit? (yes)
* If we have synchronous_commit = off do we ignore
synchronous_replication = on (yes)
* If two transactions commit almost simultaneously and one is sync and
the other async then only the sync backend will wait? (Yes)
Do we definitely need the archiver to move the files written by
walreceiver to archive and then move them back out again? Seems like we
can streamline that part in many (all?) cases.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-03 14:35:33 | Re: [PATCHES] GIN improvements |
Previous Message | Tom Lane | 2008-12-03 14:30:55 | Re: tuplestore potential performance problem |