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
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 |