Hi,
On Mon, Dec 22, 2008 at 1:29 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> Not so simple.
>
> At least the primary has to additionally maintain the byte position the standby
> has already fsynced. The main difference from the current patch is whether
> the standby fsyncs the logfile when it fills even if you don't choose #4(fsync).
> In order to prevent from having to go back and re-open prior logfiles when an
> fsync request comes along later, we would need to ignore the sync mode and
> make the standby fsync the logfile when it fills. This would degrade the
> performance periodically. Is this acceptable?
>
> I think there are four choices. Which do you prefer?
>
> 1) Accept the above change.
> 2) Go back and re-open prior logfiles when a fsync request comes along.
> 3) Stop the sync control by the primary and leave it to the standby.
> 4) Add new option to specify whether to permit optimistic fsync, this option
> makes the standby fsync only the current logfile when a fsync request
> comes along (don't go back and re-open prior logfiles).
>
> 2) would cause another performance degradation. 4) would furthermore
> confuse users about setting a sync mode. So, I prefer 3) though I'm sorry
> for digging up the discussion about transaction control. Please feel free
> to comment!
5) Only allow optimistic fsync
I'm going to adopt 5) for next patch at least for a while.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center