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: Sync Rep: First Thoughts on Code |
Date: | 2008-12-04 07:10:52 |
Message-ID: | 3f0b79eb0812032310j19195f7btb99265e0d6a12b35@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, Dec 3, 2008 at 11:33 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2008-12-04 07:21:04 | Re: In-place upgrade: catalog side |
Previous Message | Greg Smith | 2008-12-04 06:18:44 | Re: Simple postgresql.conf wizard |