| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal for 9.1: WAL streaming from WAL buffers |
| Date: | 2010-06-30 02:06:18 |
| Message-ID: | 201006300206.o5U26IO14657@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Mon, 2010-06-21 at 18:08 +0900, Fujii Masao wrote:
>
> > The problem is not that the master streams non-fsync'd WAL, but that the
> > standby can replay that. So I'm thinking that we can send non-fsync'd WAL
> > safely if the standby makes the recovery wait until the master has fsync'd
> > WAL. That is, walsender sends not only non-fsync'd WAL but also WAL flush
> > location to walreceiver, and the standby applies only the WAL which the
> > master has already fsync'd. Thought?
>
> Yes, good thought. The patch just applied seems too much.
>
> I had the same thought, though it would mean you'd need to send two xlog
> end locations, one for write, one for fsync. Though not really clear why
> we send the "current end of WAL on the server" anyway, so maybe we can
> just alter that.
Is this a TODO?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-06-30 02:09:21 | Re: Cannot cancel the change of a tablespace |
| Previous Message | Fujii Masao | 2010-06-30 02:03:38 | Re: warning message in standby |