By my reading of the code, once a live-backup client has read all currently available data in the transaction log, it will block and wait until the next time we fully flush transaction log data to the physical disk (ie, an 'fsync' or equivalent operation). This is not equivalent to simply writing a log page. Typically, we will do an fsync when a COMMIT is performed; however, a single large transaction (such as the insertion of a blob) might write several pages before ever doing an fsync. Fsyncs are done in other cases such as when we grow the transaction log file too.

There's good reason to wait until the fsync rather than just a write operation. Data that is written without an fsync isn't guaranteed to be on stable storage and could disappear from the filesystem in the event of a power outage. If data were sent to the client when transaction log data whenever there was as write operation, the client could (in the event of a server failure) end up with data in the log than the server does. Stated another way, the server (when restarted) could end up writing different data to pages that had been sent to the client previously. So, we wait for the fsync.

BTW, note that this mechanism doesn't guarantee that the live-backup client is only ever behind by at most one committed transaction. When the client wakes up and gets a copy of the page it was waiting for (ie, after an fsync), it operates asynchronously from the server. There could be lots of activity at the server while the client is writing that newly acquired page to its local filesystem and the database server will not wait for the client to catch up. For that sort of thing, you need the high availability feature.