The efficiency of the WAL log writer

Recently I became curious about the WAL log writer. I noticed that with
a default ACID complaint configuration that the the WAL log writer wakes
up every 200 msec (the default indicated by "wal_log_writer") and does
nothing. Here's a typical strace:
21:37:07.194809 select(0, NULL, NULL, NULL, {0, 31914}) = 0 (Timeout)
<0.032059>
21:37:07.227098 getppid() = 4979 <0.000018>
21:37:07.227198 select(0, NULL, NULL, NULL, {0, 200000}) = 0 (Timeout)
<0.200287>
21:37:07.427609 getppid() = 4979 <0.000023>
and ltrace:
21:37:36.265849 getppid() = 4979 <0.000200>
21:37:36.266299 select(0, 0, 0, 0, 0x7fff2ffec9c0) = 0 <0.200442>
21:37:36.466979 getppid() = 4979 <0.000154>
21:37:36.467255 select(0, 0, 0, 0, 0x7fff2ffec9c0) = 0 <0.200442>
It's possible it's doing something useful, such as with shared memory,
that is not revealed by strace and ltrace, but my question is - For at
least default ACID complaint configurations where each write is made to
the WAL logs immediately what, if anything, is the WAL log writer
polling? And if the WAL log writer is polling for something could it
instead wait on a condition which would then be signaled?

I don't think the current behavior is particularly harmful, but maybe
PostgreSQL could be made to idle more quietly. I have not investigated
the other PostgreSQL processes as closely, but some of them appear to
behave in a similar manner.

--
------------------------------------------------------------------------
| Steven Elliott | http://selliott.org | selliott4(at)austin(dot)rr(dot)com |
------------------------------------------------------------------------