AFAIK the wal writer process.
>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.
Again, thanks David and Adrian for your help
Kind Regards
Daniel
