From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | <furuyao(at)pm(dot)nttdata(dot)co(dot)jp>, <masao(dot)fujii(at)gmail(dot)com> |
Cc: | <sawada(dot)mshk(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <teranishih(at)nttdata(dot)co(dot)jp> |
Subject: | Re: pg_receivexlog --status-interval add fsync feedback |
Date: | 2014-10-08 11:50:07 |
Message-ID: | 543524EF.2040009@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/08/2014 11:47 AM, furuyao(at)pm(dot)nttdata(dot)co(dot)jp wrote:
>> On 10/08/2014 07:23 AM, furuyao(at)pm(dot)nttdata(dot)co(dot)jp wrote:
>>>> What set of options would you pass if you want to use it as a
>>>> synchronous standby? And if you don't? Could we just have a single
>> "--synchronous"
>>>> flag, instead of -F and --reply-fsync?
>>>
>>> If you set "synchronous_commit" as "remote_write", the options would
>> be different .
>>> The set of options in each case, see the following.
>>>
>>>
>>> Synchronous standby(synchronous_commit=on)
>>> --fsync-interval=-1
>>> --reply-fsync
>>> --slot=slotname
>>>
>>> Synchronous standby(synchronous_commit=remote_write)
>>> --fsync-interval=-1
>>> --reply-fsync
>>>
>>> Asynchronous
>>> There are no relative options.
>>>
>>>
>>> Well, if the response time delay(value of
>> "--status-interval=interval") is acceptable, "--reply-fsync" is
>> unnecessary.
>>> Instead of "--reply-fsync", using "--synchronous"(which summarizes
>> the "--reply-fsync" and "fsync-interval = -1") might be easy to
>> understand. Although, in that case, "--fsync-interval=interval" would
>> be fixed value. Isn't there any problem ?
>>
>> I think we should remove --fsync-interval and --reply-fsync, and just
>> have a --synchronous option, which would imply the same behavior you get
>> with --fsync-interval=-1 --reply--fsync.
>>
>> That leaves the question of whether pg_receivexlog should do fsyncs when
>> it's not acting as a synchronous standby. There isn't any real need to
>> do so. In asynchronous mode, there are no guarantees anyway, and even
>> without an fsync, the OS will eventually flush the data to disk.
>>
>> But we could do even better than that. It would be best if you didn't
>> need even the --synchronous flag. The server knows whether the client
>> is a synchronous standby or not. It could tell the client.
>
> If we remove --fsync-interval, resoponse time to user will not be delay.
> Although, fsync will be executed multiple times in a short period.
> And there is no way to solve the problem without --fsync-interval, what should we do about it?
I'm sorry, I didn't understand that.
> In asynchronous mode, I think there is no problem since the specification is same with release version.
>
>> The server knows whether the client is a synchronous standby or not.
>> It could tell the client.
>
> When notifying the synchronous/asynchronous mode to the client from the server,
> do we need to change the format of the Message ?
Yeah. Or rather, add a new message type, to indicate the
synchronous/asynchronous status.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-10-08 12:47:44 | Re: Wait free LW_SHARED acquisition - v0.2 |
Previous Message | Andres Freund | 2014-10-08 11:40:08 | Re: Patch to support SEMI and ANTI join removal |