Re: a raft of parallelism-related bug fixes

On 02/08/2016 10:45 AM, Robert Haas wrote:
> On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On 2016-02-02 15:41:45 -0500, Robert Haas wrote:

>> I realize that this stuff has all been brewing long, and that there's
>> still a lot to do. So you gotta keep moving. And I'm not sure that
>> there's anything wrong or if there's any actually better approach. But
>> pushing an unreviewed, complex patch, that originated in a thread
>> orginally about different relatively small/mundane items, for a
>> contentious issue, a few days after the initial post. Hm. Not sure how
>> you'd react if you weren't the author.
>
> Probably not very well. Do you want me to revert it?

If I am off base, please feel free to yell Latin at me again but isn't
this exactly what different trees are for in Git? Would it be possible
to say:

Robert says, "Hey pull XYZ, run ABC tests. They are what the parallelism
fixes do"?

I can't review this patch but I can run a test suite on a number of
platforms and see if it behaves as expected.

> albatross around my neck - totally ignored by everyone - until the end
> of the last CF, and then the discussion would have gone one of three
> ways:
>
> 1. Boy, this patch is complicated and I don't understand it. Let's
> reject it, even though without it parallel query is trivially broken!
> Uh, we'll just let parallel query be broken.
> 2. Like #1, but we rip out parallel query in its entirety on the eve of beta.
> 3. Oh well, Robert says we need this, I guess we'd better let him commit it.

4. We need to push the release so we can test this.

>
> I don't find any of those options to be better than the status quo.
> If the patch is broken, another two months of having in the tree give
> us a better chance of finding the bugs, especially because, combined

I think this further points to the need for more reviewers and less
feature pushes. There are fundamental features that we could use, this
is one of them. It is certainly more important than say pgLogical or BDR
(not that those aren't useful but that we do have external solutions for
that problem).

> Oh: another thing that I would like to do is commit the isolation
> tests I wrote for the deadlock detector a while back, which nobody has
> reviewed either, though Tom and Alvaro seemed reasonably positive
> about the concept. Right now, the deadlock.c part of this patch isn't
> tested at all by any of our regression test suites, because NOTHING in
> deadlock.c is tested by any of our regression test suites. You can
> blow it up with dynamite and the regression tests are perfectly happy,
> and that's pretty scary.

Test test test. Please commit.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.