Re: Additional options for Sync Replication

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Additional options for Sync Replication
Date: 2011-03-28 15:40:10
Message-ID: AANLkTi=y_D-bAPFgtccSrAgdN75aZX7LyjrBrxQ0pcur@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 28, 2011 at 3:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> It might not be dangerous, but the standby currently sends write,
> flush, and apply positions back separately, so the master must decide
> which of those to pay attention to, unless we rework the whole design.
>  I actually think the current design is quite nice and am in no hurry
> to rejigger that particular part of it.

In particular what I like about the current design is that there's no
reason you shouldn't be able to change the commit durability setting
per-transacion. You might want to have logging records be
asynchronous, regular operations be synchronous on the master, and
opeations involving money block until the slave has received them or
synced them or even applied them. Or you might want to mark just the
transactions affecting the data that your read-only queries which are
load-balanced on slaves as blocking until the slave has applied them
so people don't see inconsistent old data making it look like the
transaction failed.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-03-28 15:43:54 Re: Recursive containment of composite types
Previous Message Andrew Dunstan 2011-03-28 15:35:44 Re: Recursive containment of composite types