From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synchronous Log Shipping Replication |
Date: | 2008-09-08 21:40:39 |
Message-ID: | 200809082140.m88Ledg00897@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao wrote:
> On Mon, Sep 8, 2008 at 8:44 PM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> >> Merge into WAL writer?
> >
> > Uh.. that would mean you'd loose parallelism between WAL writing to disk and
> > WAL shipping via network. That does not sound appealing to me.
>
> That depends on the order of WAL writing and WAL shipping.
> How about the following order?
>
> 1. A backend writes WAL to disk.
> 2. The backend wakes up WAL sender process and sleeps.
> 3. WAL sender process does WAL shipping and wakes up the backend.
> 4. The backend issues sync command.
I am confused why this is considered so complicated. Having individual
backends doing the wal transfer to the slave is never going to work
well.
I figured we would have a single WAL streamer that continues advancing
forward in the WAL file, streaming to the standby. Backends would
update a shared memory variable specifying how far they want the wal
streamer to advance and send a signal to the wal streamer if necessary.
Backends would monitor another shared memory variable that specifies how
far the wal streamer has advanced.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2008-09-08 21:53:20 | Re: Common Table Expressions (WITH RECURSIVE) patch |
Previous Message | Martin Pihlak | 2008-09-08 21:10:48 | Re: reducing statistics write overhead |