Hi,
Fujii Masao wrote:
> 1. A backend writes WAL to disk.
> 2. The backend wakes up WAL sender process and sleeps.
> 3. WAL sender process does WAL shipping and wakes up the backend.
> 4. The backend issues sync command.
Right, that would work. But still, the WAL writer process would block
during writing WAL blocks.
Are there compelling reasons for using the existing WAL writer process,
as opposed to introducing a new process?
> The timing of the process's receiving a signal is dependent on the scheduler
> of kernel.
Sure, so are pipes or shmem queues.
> The scheduler does not always handle a signal immediately.
What exactly are you proposing to use instead of signals? Semaphores are
pretty inconvenient when trying to wake up arbitrary processes or in
conjunction with listening on sockets via select(), for example.
See src/backend/replication/manager.c from Postgres-R for a working
implementation of such a process using select() and signaling.
Regards
Markus Wanner
