The flush methods write the log tail to the corresponding page on disk. An issue is to compute the last LSN that made it to disk when this write succeeds. Since LSNs determine positions and LSNs can be compared using <, >, etc., we return the last LSN flushed as one less than global_shm_log_ptr->sl_nextlsn. This works because we are not interested in the LSN of the last log record that made it to disk but an LSN that can be used to enforce WAL. The private method next_lsn_less_1 computes this.
The flush methods do nothing if the log is empty.
Much of the functionality in these two methods are common. The common part is in internal_flush. This is called by both methods to do all the work.
This concludes our discussion of the implementation details of the log manager. Additional details can be found in the documentation in the code itself.