I wanted to scrub a table by processing each row, but without holding locks, so I wanted to commit every few hundred rows, but with only ACI and not D, since I could just run the process again. I don't think Postgres supports this feature. It also seemed to be calling fsync much more than once per transaction.
If it's called many more times than once per transaction the likely reason is that wal_buffers is sized small. Whenever generated WAL exceeds wal_buffers, postgres flushes the WAL, so it does not have to reopen the file later. At that point you already gotten most benefits from batching too.
Edit: A second reason is that data pages need to be written out due to cache pressure or such, and that requires the WAL to be flushed first.
[1]: https://www.postgresql.org/docs/current/non-durability.html
https://www.postgresql.org/docs/current/runtime-config-wal.h...
Don't use synchronous_commit = off is durability ~= 0 (i.e. "I hope the write made it to disk")
BEGIN
INSERT … —- batch of N size
COMMIT AND CHAIN
INSERT …