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

Re: disposition of remaining patches

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: disposition of remaining patches
Date: 2011-02-25 23:44:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Right now, as it stands, the syncrep patch will be happy as soon as
> the data has been fsynced to either B or A-prime; I don't think we can
> guarantee at any point that A-prime can become the leader, and feed B.

Yeah, I think that's something we said months ago is going to be a 9.2
feature, no sooner.

> 2. The unprivileged user can disable syncrep, in any situation. This
> flexibility is *great*, but you don't really want people to do it when
> one is performing the switchover. Rather, in a magical world we'd hope
> that disabling syncrep would just result in not having to
> synchronously commit to B (but, in this case, still synchronously
> commit to A-prime)
> In other words, to my mind, you can use syncrep as-is to provide
> 2-safe durability xor a scheduled switchover: as soon as someone wants
> both, I think they'll have some trouble. I do want both, though.

Hmmm, I don't follow this.  The user can only disable syncrep for their
own transactions.   If they don't care about the persistence of their
transaction post-failover, why should the DBA care?

                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-26 00:00:11
Subject: Re: wCTE: about the name of the feature
Previous:From: Josh BerkusDate: 2011-02-25 23:41:09
Subject: Re: WIP: cross column correlation ...

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