On 06/09/10 16:03, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> (scratches head..) What's the point of differentiating
>> received/fsynced/replayed, if the master receives the ack for all of them at
>> the same time?
>
> It wouldn't the way I understand Simon's proposal.
>
> What's happening is that the feedback channel is periodically sending an
> array of 3 LSN, the currently last received, fsync()ed and applied ones.
"Periodically" is a performance problem. The bottleneck in synchronous
replication is typically the extra round-trip between master and
standby, as the master needs to wait for the acknowledgment. Any delays
in sending that acknowledgment lead directly to a decrease in
performance. That's also why we need to eliminate the polling loops in
walsender and walreceiver, and make them react immediately when there's
work to do.
>> Let's try this with an example: In the master, I do stuff and commit a
>> transaction. I want to know when the transaction is fsynced in the
>> standby. The WAL is sent to the standby, up to the commit record.
> [...]
>> So, when does standby send the single message back to the master?
>
> The standby is sending a stream of messages to the master with current
> LSN positions at the time the message is sent. Given a synchronous
> transaction, the master would wait until the feedback stream reports
> that the current transaction is in the past compared to the streamed
> last known synced one (or the same).
That doesn't really answer the question: *when* does standby send back
the acknowledgment?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com