Skip site navigation (1) Skip section navigation (2)

Re: Synchronous replication - patch status inquiry

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-09-01 05:45:05
Subject: array_agg() NULL Handling
Previous:From: Pavel StehuleDate: 2010-09-01 04:29:28
Subject: Re: string function - "format" function proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group