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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
