Re: a raft of parallelism-related bug fixes

On 9 February 2016 at 03:00, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

>
> 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).

Well, with the pglogical and BDR work most of the work has been along
similar lines - getting the infrastructure in place. Commit timestamps,
logical decoding, and other features that are useful way beyond
pglogical/BDR. Logical decoding in particular is rapidly becoming a really
significant feature as people start to see the potential for it in
integration and ETL processes.

I'm not sure anyone takes the pglogical downstream submission as a serious
attempt at inclusion in 9.6, and even submitting the upstream was
significantly a RFC at least as far as 9.6 is concerned. I don't think the
downstream submission took any significant time or attention away from
other work.

The main result has been useful discussions on remaining pieces needed for
DDL replication etc and some greater awareness among others in the
community about what's going on in the area. I think that's a generally
useful thing.

>
>
> 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.
>
>
Yeah. Enhancing the isolation tests would be useful. Please commit those
changes. Even if they broke something in the isolation tester - which isn't
likely - forward movement in test infrastructure is important and we should
IMO have a lower bar for committing changes there. They won't directly
affect code end users are running.

I should resurrect Abhijit's patch to allow the isolationtester to talk to
multiple servers. We'll want that when we're doing tests like "assert that
this change isn't visible on the replica before it becomes visible on the
master". (Well, except we violate that one with our funky
synchronous_commit implementation...)

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