Re: Additional options for Sync Replication - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Additional options for Sync Replication
Date
Msg-id AANLkTi=y_D-bAPFgtccSrAgdN75aZX7LyjrBrxQ0pcur@mail.gmail.com
Whole thread Raw
In response to Re: Additional options for Sync Replication  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Mar 28, 2011 at 3:42 PM, Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Recursive containment of composite types
Next
From: Tom Lane
Date:
Subject: Re: Recursive containment of composite types