On 06/09/10 16:03, Dimitri Fontaine wrote:
Heikki Linnakangas<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
