On Wed, Mar 30, 2011 at 5:29 AM, Fujii Masao masao.fu...@gmail.com wrote:
I'm very excited about new options, especially recv. But I agree with
Robert and Heikki because what the patch provides looks like new
feature rather than bug fix. And I think that we still require some
discussions of
Yeb Havinga yebhavi...@gmail.com writes:
The dba interface for recv|fsync|apply seems to be pretty stable, so
supporting that for years should be without risk. How it works under the
hood - the beta period seems like *the* opportunity to attrach mayor testing
from all people waiting to get
On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
It would be better to just support it (recv|fsync|apply),
or no syncrep at all. Syncrep is incomplete without it.
Agreed.
I have trouble viewing the idea that it would be better not to ship
sync rep at all than to
Robert Haas robertmh...@gmail.com writes:
If we accept this patch now because a bunch of
people say they really, really want it, isn't that unfair to the
people to whom we've already said sorry, the deadline has passed?
No, because each time we're talking procedures we're forgetting about a
On Tue, Mar 29, 2011 at 12:57 PM, Robert Haas robertmh...@gmail.com wrote:
However, we also
bumped MANY patches to 9.2 because they weren't in sufficiently good
shape soon enough. If we accept this patch now because a bunch of
people say they really, really want it, isn't that unfair to the
On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
So the rules are not the same for commiter patches and contributor
patches, and there's no good in trying to have them the same or
pretending they are. In particular, only commiters are able to finish
and polish
On Tue, Mar 29, 2011 at 5:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
So the rules are not the same for commiter patches and contributor
patches, and there's no good in trying to have them the same or
On 3/29/11 7:48 AM, Dimitri Fontaine wrote:
I don't want a release as soon as possible, I want the best we are able
to provide, and I think adding in current $subject patch helps reaching
this goal. include baring show stoppers QA disclaimer
There will *always* be more work we can do on sync
On Tue, Mar 29, 2011 at 2:48 PM, Josh Berkus j...@agliodbs.com wrote:
Writing such long emails seems to be just filibustering to me. I doubt
anyone has read and considered every word, there are just too many. A
form of disrespect.
Simon, Robert has been nothing but respectful to you. You
On Tue, Mar 29, 2011 at 7:48 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/29/11 7:48 AM, Dimitri Fontaine wrote:
I don't want a release as soon as possible, I want the best we are able
to provide, and I think adding in current $subject patch helps reaching
this goal. include baring show
On Tue, Mar 29, 2011 at 7:48 PM, Josh Berkus j...@agliodbs.com wrote:
Writing such long emails seems to be just filibustering to me. I doubt
anyone has read and considered every word, there are just too many. A
form of disrespect.
Simon, Robert has been nothing but respectful to you. You
On Tue, Mar 29, 2011 at 8:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
It would be better to just support it (recv|fsync|apply),
or no syncrep at all. Syncrep is incomplete without it.
Agreed.
I have trouble
On Sun, Mar 27, 2011 at 11:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 27, 2011 at 5:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to
On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark gsst...@mit.edu wrote:
Also, for what it's worth I prefer thinking of
synchronous_commit/synchronous_replication as one big multi-way
variable:
synchronous_commit = memory | disk | replica-memory | replica-disk |
replica-visible
That's close
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Why is this even a discussion point?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Why is this even a discussion point?
FWIW, I agree this is an
On Mon, Mar 28, 2011 at 6:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Huh? There is an open item about
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com
wrote:
You have no basis on which to prevent this.
It's also already on the Open Items
On Mon, Mar 28, 2011 at 10:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark gsst...@mit.edu wrote:
Also, for what it's worth I prefer thinking of
synchronous_commit/synchronous_replication as one big multi-way
variable:
synchronous_commit =
On 28.03.2011 15:34, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com
wrote:
You have no basis on which to prevent
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com wrote:
but there is certainly no
open item for adding additional sync rep modes.
In your opinion.
We will have to live with the UI for a long time, yes. I'm trying to
get it right, whether that includes adding an obvious/easy
On Mon, Mar 28, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com wrote:
but there is certainly no
open item for adding additional sync rep modes.
In your opinion.
Well, as you just pointed out yourself a few minutes
On 28.03.2011 15:54, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haasrobertmh...@gmail.com wrote:
but there is certainly no
open item for adding additional sync rep modes.
In your opinion.
Huh? First you say that Robert added an open item about this to the
list, he says
On Mon, Mar 28, 2011 at 1:51 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The 'apply' mode would be quite interesting, it would make it easier to
build load-balancing clusters. But the patch isn't up to the task on that
yet - the 'apply' status report is only sent after
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the standby.
Now you are being ridiculous. You've spoken strongly against this at
every single step of this journey.
We're well passed the stage
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the standby.
Now you are being ridiculous. You've spoken strongly against this at
every single step of
On Mon, Mar 28, 2011 at 10:11 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the
On Mon, Mar 28, 2011 at 3:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the
Robert Haas robertmh...@gmail.com wrote:
We also need to consider the issue raised elsewhere - that a naive
implementation of this could allow the commit to become visible on
the standby before it becomes visible on the master. That would
be expensive to prevent, because you'd need an
On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a simple patch, containing functionality already discussed and
agreed and for which code was submitted in this CF.
These statements are simply not accurate. It isn't a simple patch,
the details of how the write
On Mon, Mar 28, 2011 at 3:42 PM, Robert Haas robertmh...@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
On Mon, Mar 28, 2011 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a simple patch, containing functionality already discussed and
agreed and for which code was submitted in this CF.
These statements are
On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggssi...@2ndquadrant.com wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta,
On Sun, Mar 27, 2011 at 5:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta,
On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta,
35 matches
Mail list logo
