Hi, On Mon, Dec 22, 2008 at 1:29 PM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers