Commit effect on WAL-Writer behaviour

Hello,

Coming from a Db2 – mainframe world trying to understand Postgres.  Kindly forgive my ignorance and the somewhat long winded question.  

  When a particular transaction TRAN1, inserts/updates/deletes data, the changes are made to the memory blocks in the  Shared Buffer ( data buffers ) and corresponding Undo and Redo Logs are written to the Log buffers.  While

TRAN1 is running , TRAN2 TRAN3 …. TRAN4 can run concurrently and be writing information tot he WAL-Buffers.

  Let us assume that TRAN1 began at 0000 Hours and at has updated 1 rows at 0001 Hours.

 Let us further assume for simplicity that TRAN1 TRAN2 TRAN3 and TRAN4 have updated 1 row each and written 2 WAL-Records each in the WAL-Buffer BUT  NOT issued a COMMIT yet.

 Now at 0002 Hours TRAN4 alone has issued a COMMIT.

Will all the 8  WAL-Buffer records be written to the WAL files?  Obviously TRAN1 2 and 3 are  IN-FLIGHT ( un committed ) at 0902 Hours, while TRAN4 is committed.  ( This is how DB2 works . When a COMMIT is issued by any transaction ALL the log buffers are written to disk, immaterial of if they are commited or not. There is a BEGIN Unit of Recovery Log record, a END Unit of Recovery log Record associated with each transaction . Each Unit of Recovery is an unique identifier. Every log record that belongs to this Unit of Recovery ID has this identifier in it.  So after a crash, the logs are scanned forward since the last check point and only those logrecords with a matching BEGIN UR and END UR are redone, and those with just a BEGIN UR and no matching END UR are rolled back.

Does a COMMIT even cause the ALL the WAL-Buffers to be written to WAL-Files in Postgres?

If not what exactly does a COMMIT do? how can one force a write of the WAL-Buffers to disk with a SQL command?

Thank you for your time.

Ram