Re: disposition of remaining patches - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: disposition of remaining patches
Date
Msg-id AANLkTi=JVBLoRqpy7AsKHw5RqGG6Xf0HMdox40C8KdmM@mail.gmail.com
Whole thread Raw
In response to Re: disposition of remaining patches  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: disposition of remaining patches
List pgsql-hackers
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina <daniel@heroku.com> wrote:
>> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith <greg@2ndquadrant.com> wrote:
>>> Robert Haas wrote:
>>>>>
>>>>> 2. Synchronous replication.  Splitting up this patch has allowed some
>>> On top of 4 listed reviewers I know Dan Farina is poking at the last update,
>>> so we may see one more larger report on top of what's already shown up.  And
>>> Jaime keeps kicking the tires too.  What Simon was hoping is that a week of
>>> others looking at this would produce enough feedback that it might be
>>> possible to sweep the remaining issues up soon after he's back.  It looks to
>>> me like that's about when everything else that's still open will probably
>>> settle too.
>>
>> Besides some of the fixable issues, I am going to have to echo
>> Robert's sentiments about a few kinks that go beyond mechanism in the
>> syncrep patch: in particular, it will *almost* solve the use case I
>> was hoping to solve: a way to cleanly perform planned switchovers
>> between machines with minimal downtime and no lost data. But there are
>> a couple of holes I have thought of so far:
>
> Well, just because the patch doesn't solve every use case isn't a
> reason not to go forward with it - we can always add more options
> later - but I have to admit that I'm kind of alarmed about the number
> of bugs reported so far.

True: the relevance of any use case to acceptance is up to some
debate. I haven't thought about how to remedy this, just thinking
aloud about a problem I would have as-is, and is important to me.  It
is true that later accretion of options can occur, but sometimes the
initial choice of semantics can make growing those easier or harder.
I haven't yet thought ahead as to how the current scheme would impact
that.

I know I got hit by a backend synchronization (in the sense of locks,
etc) bugs; do you think it is possible yours (sending SIGSTOP) could
be the same root cause? I haven't followed all the other bugs cleared
up by inspection.

--
fdr


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: WIP: cross column correlation ...
Next
From: Jaime Casanova
Date:
Subject: Re: Sync Rep v17