On 10/09/2014 07:47 AM, furu...@pm.nttdata.co.jp wrote:
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.
Here is an example.
When WAL is sent at 100ms intervals, fsync() is executed 10 times per second.
If --fsync-interval is set by 1 second, we have to wait SQL responce(kind of
making WAL record) for 1 second, though, fsync() won't be executed several
times in 1 second.
I think --fsync-interval meets the demands of people who wants to restrain
fsync() happens for several time in short period, but what do you think?
Is it ok to delete --fsync-interval ?
I still don't see the problem.
In synchronous mode, pg_receivexlog should have similar logic as
walreceiver does. It should read as much WAL from the socket as it can
without blocking, and fsync() and send reply after that. And also fsync
whenever switching to new segment. If the master sends WAL every 100ms,
then pg_recevexlog will indeed fsync() 10 times per second. There's
nothing wrong with that.
In asynchronous mode, only fsync whenever switching to new segment.
Yeah. Or rather, add a new message type, to indicate the
synchronous/asynchronous status.
What kind of 'message type' we have to add ?
Do we need to separate 'w' into two types ? synchronous and asynchronous ?
OR
Add a new message type, kind of 'notify synchronous',
and inform pg_receivexlog of synchronous status when it connect to the server.
Better to add a new "notify" message type. And pg_recevexlog should be
prepared to receive it at any time. The status might change on the fly,
if the server's configuration is reloaded.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
