Re: New sync commit mode remote_write

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New sync commit mode remote_write
Date: 2012-04-20 19:58:59
Message-ID: CAHGQGwEtQogo=03yoZVDQE5bWWL86X3vG0EURL8e0A_8XZruRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 21, 2012 at 12:20 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Apr 19, 2012 at 7:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On 4/19/12, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> The work around would be for the master to refuse to automatically
>>> restart after a crash, insisting on a fail-over instead (or a manual
>>> forcing of recovery)?
>>
>> I suppose that would work, but I think Simon's idea is better: don't
>> let the slave replay the WAL until either (a) it's promoted or (b) the
>> master finishes the fsync.   That boils down to adding some more
>> handshaking to the replication protocol, I think.
>
> It would be 8 bytes on every data message sent to the standby.

There seems to be another problem to solve. In current design of streaming
replication, we cannot send any WAL records before writing them locally.
Which would mess up the mode which makes a transaction wait for remote
write but not local one. We should change walsender so that it can send
WAL records before they are written, e.g., send from wal_buffers?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2012-04-21 01:33:01 Re: RANGE type, and its subtype parameter
Previous Message Tom Lane 2012-04-20 17:18:50 Re: Plan stability versus near-exact ties in cost estimates