From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synchronous Log Shipping Replication |
Date: | 2008-09-08 15:15:25 |
Message-ID: | 48C5418D.9030401@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-09-08 15:16:51 | Re: [PATCH] Cleanup of GUC units code |
Previous Message | Jeff Davis | 2008-09-08 15:12:23 | Common Table Expressions (WITH RECURSIVE) patch |