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