| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Synchronous replication - patch status inquiry |
| Date: | 2010-09-01 05:33:07 |
| Message-ID: | 4C7DE593.9040306@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/09/10 04:02, Robert Haas wrote:
> See the thread on interruptible sleeps. The problem
> right now is that there are some polling loops that act to throttle
> the maximum rate at which a node doing sync rep can make forward
> progress, independent of the capabilities of the hardware.
To be precise, the polling doesn't affect the "bandwidth" the
replication can handle, but it introduces a delay wh
> Those need
> to be replaced with a system that doesn't inject unnecessary delays
> into the process, which is what Heikki is working on.
Right.
Once we're done with that, all the big questions are still left. How to
configure it? What does synchronous replication mean, when is a
transaction acknowledged as committed? What to do if a standby server
dies and never acknowledges a commit? All these issues have been
discussed, but there is no consensus yet.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2010-09-01 05:45:05 | array_agg() NULL Handling |
| Previous Message | Pavel Stehule | 2010-09-01 04:29:28 | Re: string function - "format" function proposal |