On 06/27/2017 11:19 AM, Daniel Westermann wrote: > > Thanks, Adrian > It is clear now for the asynchronous stuff and wal_writer. > But I still did not figure out (or I am just not able to understand it from the README linked above) > which process is actually doing the write to the wal when you have synchronous commit set to on. Can > someone put some light on this?
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 the 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.
