Markus Wanner <[EMAIL PROTECTED]> 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 prototype use 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 locking and 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
