Re: Streaming Replication patch for CommitFest 2009-09

Hi,

On Fri, Sep 25, 2009 at 7:10 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Fujii Masao wrote:
>> On Thu, Sep 24, 2009 at 7:57 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>>> - I know I said we should have just asynchronous replication at first,
>>>>> but looking ahead, how would you do synchronous?
>>>> As the previous patch did, I'm going to make walsender read the latest
>>>> XLOG from wal_buffers, introduce the signaling between a backend
>>>> and walsender, and keep a backend waiting until the specified XLOG
>>>> has been written or fsynced in the standby.
>>> Ok. I don't think walsender needs to access wal_buffers even then,
>>> though. Once the backend has written the WAL, walsender can well read it
>>> from disk (it will surely be in OS cache still).
>>
>> I think that walsender should not delay sending the XLOG until it has
>> been written by the backend, for performance improvement. Otherwise,
>> XLOG write and send are performed in serial, which would increase a
>> response time. Should those be performed in parallel?
>
> Well, sure, performance is good, but let's keep it simple for now. The
> write() to disk should normally be absorbed by the OS cache and return
> quickly, so it's not a big delay.

Umm... a backend at least should tell walsender the location which it
has written the XLOG before issuing fsync. In the current XLogWrite(),
XLogCtl->LogwrtResult.Write is updated after fsync has been performed.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center