| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Synchronous Log Shipping Replication |
| Date: | 2008-09-09 10:58:48 |
| Message-ID: | 20080909192040.7BF8.52131E4D@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> The tricky part is, how does A know if it should wait, and for how long?
> commit_delay sure isn't ideal, but AFAICS the log shipping proposal
> doesn't provide any solution to that.
They have no relation each other directly,
but they need similar synchronization modules.
In log shipping, backends need to wait for WAL Sender's job,
and should wake up as fast as possible after the job is done.
It is similar to requirement of the group commit.
Signals and locking, borrewed from Postgres-R, are now studied
for the purpose in the log shipping, but I'm not sure it can be
also used in the group commit.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brendan Jurd | 2008-09-09 11:04:39 | Re: [PATCHES] to_date() validation |
| Previous Message | Gregory Stark | 2008-09-09 10:20:26 | Re: Our CLUSTER implementation is pessimal |