Re: Synchronous Log Shipping Replication

Markus Wanner <markus@bluegap.ch> wrote:

> ITAGAKI Takahiro wrote:
> > Are there any better idea to share one socket connection between
> > backends (and bgwriter)?
>
> I fear I'm repeating myself, but I've had the same problem for 
> Postgres-R and solved it with an internal message passing infrastructure 
> which I've simply called imessages. It requires only standard Postgres 
> shared memory, signals and locking and should thus be pretty portable.

Imessage serves as a useful reference, but it is one of the detail parts
of the issue. I can break down the issue into three parts:
 1. Is process-switching approach the best way to share one socket?       Both Postgres-R and the log-shipping
prototypeuse the approach now.       Can I think there is no objection here?
 
 2. If 1 is reasonable, how should we add a new WAL sender process?       Just add a new process using a core-patch?
  Merge into WAL writer?       Consider framework to add any of user-defined auxiliary process?
 
 3. If 1 is reasonable, what should we use for the process-switching    primitive?       Postgres-R uses signals and
lockingand the log-shipping prototype       uses multi-threads and POSIX message queues now.
 

Signals and locking is possible choice for 3, but I want to use better
approach if any. Faster is always better.

I guess we could invent a new semaphore-like primitive at the same layer
as LWLocks using spinlock and PGPROC directly...

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center