Re: Configuring synchronous replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Configuring synchronous replication
Date
Msg-id 1284717777.1733.3764.camel@ebony
Whole thread Raw
In response to Re: Configuring synchronous replication  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Configuring synchronous replication  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
On Fri, 2010-09-17 at 12:30 +0300, Heikki Linnakangas wrote:

> If the synchronicity is configured in the standby, how does the master 
> know that there's a synchronous slave out there that it should wait for, 
> if that slave isn't connected at the moment?

That isn't a question you need standby registration to answer.

In my proposal, the user requests a certain level of confirmation and
will wait until timeout to see if it is received. The standby can crash
and restart, come back and provide the answer, and it will still work.

So it is the user request that informs the master that there would
normally be a synchronous slave out there it should wait for.

So far, I have added the point that if a user requests a level of
confirmation that is currently unavailable, then it will use the highest
level of confirmation available now. That stops us from waiting for
timeout for every transaction we run if standby goes down hard, which
just freezes the application for long periods to no real benefit. It
also prevents applications from requesting durability levels the cluster
cannot satisfy, in the opinion of the sysadmin, since the sysadmin
specifies the max level on each standby.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Configuring synchronous replication
Next
From: Heikki Linnakangas
Date:
Subject: Re: Configuring synchronous replication