On Tue, Jun 27, 2017 at 3:52 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote:
> 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. David J.
