Re: disposition of remaining patches

On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith <greg(at)2ndquadrant(dot)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