Hi,
On Wed, Dec 17, 2008 at 12:07 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
>> No, we've been through that loop already a few months back:
>> Transaction-controlled robustness.
>>
>> It should be up to the client on the primary to decide how much waiting
>> they would like to perform in order to provide a guarantee. A change of
>> setting on the standby should not be allowed to alter the performance or
>> durability on the primary.
>
> OK. I will extend synchronous_replication, make walsender send XLOG
> with synchronization mode flag and make walreceiver perform according
> to the flag.
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!
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
