>Um, no. "Synchronous" means that the caller has to wait for the result to appear before it can move on. "Asynchronous" means that >he caller can issue the instruction and immediately move on. I guessing here but while usually the caller would have to provide >callback hook to get the answer in the future in this case the caller is assuming a positive result and doesn't listen for a response. It is >for the asynchronous mode that wal_writer exists. In synchronous mode it would be somewhat inefficient to hand-off/leave the work to >a separate process to perform while the main process remains idle - better to just have the main process do it. Its not a total win since >the WAL file takes on the inherent contention.
>
>The linked readme (and I suspect much of the docs) was written under the assumption that the calling session performs all work not >otherwise explicitly designated as being handled by a separate process. That is why you cannot find an affirmative answer to the >posed question - it is taken as something having been previously learned (or deduced in my case - the others links being illustrative >too).
>Now, I'm still just going off of human documentation and not the actual code - but my confidence level is quite high.
Seems I am not the only one who is confused here. To summarize: When synchronous_commit is set to on it is the user session that does the write to the wal. When synchronous_commit is set to off (which means asynchronous commit) it is the job of the wal_writer to (batch) commit what needs to be commited since the last flush (can be configured with wal_writer_delay).
Maybe it is worth to enhance the documentation for this, at least for synchronous_commit=true? The asynchronous behavior is well documented here: https://www.postgresql.org/docs/current/static/wal-async-commit.html.
