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

Re: Synchronous replication & Hot standby patches

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: jd(at)commandprompt(dot)com, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "K, Niranjan (NSN - IN/Bangalore)" <niranjan(dot)k(at)nsn(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous replication & Hot standby patches
Date: 2009-02-24 20:08:02
Message-ID: 1235506082.16176.211.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2009-02-24 at 13:53 -0500, Andrew Dunstan wrote:
> Simon Riggs wrote:
> > On Tue, 2009-02-24 at 10:34 -0800, Joshua D. Drake wrote:
> >
> >   
> >> Well VLDB is like 2% of what we need. 
> >>     
> >
> > I am against removing an existing capability that is important to some
> > users. We shouldn't need to debate the exact percentage of users that
> > would be affected, or how to count them.
> >

> Perhaps so, but I would hope you would support what Heikki and others 
> have been talking about as an option for replication. The 2% shouldn't 
> hold back the remaining 98%.

So far, everything has been couched in terms of remove the way it is now
and put in its place something "better". Heikki and Josh have said that
or similar, as has Robert Haas on another thread, and Fujii-san
specifically said "get rid of" the existing functionality. I am
completely against the removal of an existing capability that is
critically important to many users.

If we can add new functionality that is a nice-to-have for a large
number of people without removing a feature that is critical to many
users, bring it on. If we can't do that, then I would oppose.

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2009-02-24 20:21:18
Subject: Re: Synchronous replication & Hot standby patches
Previous:From: Heikki LinnakangasDate: 2009-02-24 19:59:37
Subject: Re: Hot standby, recovery procs

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