Re: Sync Rep v17

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Sync Rep v17
Date: 2011-02-20 03:52:32
Message-ID: AANLkTini5VhdBCjBs3fBVPa-rNHvgX_qHaP0oA1JgQJE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> First, we should be clear to explain that you are referring to the fact
> that the request
>  synchronous_commit = off
>  synchronous_replication = on
> makes no sense in the way the replication system is currently designed,
> even though it is a wish-list item to make it work in 9.2+

What exactly do you mean by "make it work"? We can either (1) wait
for the local commit and the remote commit (synchronous_commit=on,
synchronous_replication=on), (2) wait for the local commit only
(synchronous_commit=on, synchronous_replication=off), or (3) wait for
neither (synchronous_commit=off, synchronous_replication=off).
There's no fourth possible behavior, AFAICS.

The question is whether synchronous_commit=off,
synchronous_replication=on should behave like (1) or (3); AFAICS
there's no fourth possible behavior. You have it as #1; I'm arguing
it should be #3. I realize it's an arguable point; I'm just arguing
for what makes most sense to me.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-20 04:07:46 Re: FDW API: don't like the EXPLAIN mechanism
Previous Message Josh Berkus 2011-02-20 03:31:46 Re: work_mem / maintenance_work_mem maximums