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

From Simon Riggs
Subject Re: Additional options for Sync Replication
Date
Msg-id AANLkTino4w0p4FW5KZnCcuPYa-0xOqtBYoyh7p2UZ1=V@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 4:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs <simon@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.

Then you are mistaken on every single point.


> It isn't a simple patch,

Yes, it is. Most of the patch is docs and GUC changes. The current
patch was specifically designed by me to allow this to be added. One
queue is replaced easily by 3 queues, which essentially touches only 2
places in the current code, sleep and wakeup. And it touches them in
very simple ways. Variable to Array. Easy.


> the details of how the write and apply modes should work haven't been
> fully discussed,

The original patch had all 3 modes side-by-side, all working identically.
There has never been any objection or discussion about that and its
been part of the design for months.
What different approach is there?


> and there is no version of your patch submitted for
> the last CommitFest which contains any of this functionality.

v9, submitted on 15 Jan contains this functionality.



> Moreover, that CommitFest is OVER, so your repeated references to it
> as "this CF" rather than "the last CF" do not match my view of how the
> world works.

We are still applying patches, for various reasons. I must have missed
your objections to Tom's proposals to fix un-neat things about
collations, or his additions to the extensions features. Go say what
you've said here to him as well.



>> There's no reason to block this, only for us to decide the final
>> naming of parameter/s and options.
>
> At the end of the day, we make these decisions by consensus, and three
> people have said quite clearly that they believe it is too late to
> apply something like this.

"Something like this". Well given that all of the facts on which
you've based your decision are wrong, I expect you to revise your
decision.

There is nothing about this patch that makes it possible or sensible
to exclude it. You wish to continue to discuss Network timeouts. Why
are they "in" and this "out". Both were submitted as part of my
original patch....


--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Lock problem with autovacuum truncating heap
Next
From: Joseph Adams
Date:
Subject: Another swing at JSON