Re: Synchronous Log Shipping Replication

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

In response to

Browse pgsql-hackers by date

  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