Disclaimer : I have understood things in a way that allows me to answer
here, I don't know at all if that's the way it's meant to be understood.
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.
Now what you're saying is that we should feed back this information
after each recovery step forward, what Simon is saying is that we could
have a looser coupling between the slave activity and the feedback
channel to the master.
That means the master will not see all the slave's restoring activity,
but as the LSN are a monotonic sequence that's not a problem, we can use
<= rather than = in the wait-and-wakeup loop on the master.
> 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).
Hope this helps, regards,
--
dim