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

Re: Standalone synchronous master

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <alex(dot)bjornhagen(at)gmail(dot)com>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>, "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Standalone synchronous master
Date: 2012-01-13 22:43:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I'm having a hard time seeing why this is considered a feature.  It
> seems to me what is being proposed is a mode with no higher
> integrity guarantee than asynchronous replication, but latency
> equivalent to synchronous replication.  I can see where it's
> tempting to want to think it gives something more in terms of
> integrity guarantees, but when I think it through, I'm not really
> seeing any actual benefit.

Same here, so what I think is that the new recv and write modes that
Fujii is working on could maybe be demoted from sync variant, while not
being really async ones.  Maybe “eager” or some other term.

It seems to me that would answer the OP use case and your remark here.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2012-01-13 22:47:51
Subject: Re: Multithread Query Planner
Previous:From: Dimitri FontaineDate: 2012-01-13 22:37:22
Subject: Re: Disabled features on Hot Standby

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