Hi,
Fujii Masao wrote:
> Really? In the benchmark result of my prototype, the bottleneck is
> still disk I/O.
> The communication (between the master and the slave) latency is smaller than
> WAL writing (fsyncing) one. Of course, I assume that we use not-poor network
> like 1000BASE-T.
Sure. If you do WAL sending to standby and WAL writing to disk in
parallel, only the slower one is relevant (in case you want to wait for
both). If that happens to be the disk, you won't see any performance
degradation compared to standalone operation.
If you want the standby to confirm having written (and flushed) the WAL
to disk as well, that can't possibly be faster than the active node's
local disk (assuming equally fast and busy disk subsystems).
> I'd like to introduce new parameter "synchronous_replication" which specifies
> whether backends waits for the response from WAL sender process. By
> combining synchronous_commit and synchronous_replication, users can
> choose various options.
Various config options have already been proposed. I personally don't
think that helps us much. Instead, I'd prefer to see prototype code or
at least concepts. We can juggle with the GUC variable names or other
config options later on.
> In the viewpoint of detection of a network failure, this feature is necessary.
> When the network goes down, WAL sender can be blocked until it detects
> the network failure, i.e. WAL sender keeps waiting for the response which
> never comes. A timeout notification is necessary in order to detect a
> network failure soon.
That's one of the areas I'm missing from the overall concept. I'm glad
it comes up. You certainly realize, that such a timeout must be set high
enough so as not to trigger "false negatives" every now and then? Or do
you expect some sort of retry loop in case the link to the standby comes
up again? How about multiple standby servers?
Regards
Markus Wanner
