From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Synchronous Log Shipping Replication |
Date: | 2008-09-08 10:37:55 |
Message-ID: | 48C50083.2090509@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
ITAGAKI Takahiro wrote:
> Are there any better idea to share one socket connection between
> backends (and bgwriter)? The connections could be established after
> fork() from postmaster, and number of them could be two or more.
> This is one of the most complicated part of synchronous log shipping.
> Switching-processes apporach like b) is just one idea for it.
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.
In simple benchmarks, it's not quite as efficient as unix pipes, but
doesn't require as many file descriptors, is independent of the
parent-child relations of processes, maintains message borders and it is
more portable (I hope). It could certainly be improved WRT efficiency
and could theoretically even beat Unix pipes, because it involves less
copying of data and less syscalls.
It has not been reviewed nor commented much. I'd still appreciate that.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-09-08 10:52:26 | Re: Our CLUSTER implementation is pessimal |
Previous Message | ITAGAKI Takahiro | 2008-09-08 10:19:54 | Re: Synchronous Log Shipping Replication |