Re: parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 5:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > Internal or external I do think the number and type of flags described
> here,
> > for the purposes described, seems undesirable from an architectural
> > standpoint.
>
> Well, that seems like a bold statement to me, because I think that one
> really has to understand why flags got added before deciding whether
> there are too many of them, and it's not clear to me that you do.
>

​I don't. And I totally accept a response of: you are operating under a
false premise here.​ My response above was more defensive that
constructive.

What we're talking about here is ONE flag, which currently controls
> whether the leader will participate in running Gather's child plan.
> What happens when the flag is set to "leader should not participate"
> and no workers are available? The current behavior is that the leader
> runs the plan in lieu of the workers, and Tom is proposing to change
> it so that we wait for a worker to become available instead.

​I think my biggest (again, I'm not digging deep here) misunderstanding is
testing mode versus production mode and what is or is not visible to the
test framework compared to SQL/libpq

I am usually quite happy when people other than senior hackers weigh
> in on threads here, especially about user-visible behavior, because
> senior hackers can be quite myopic. We spend most of our time
> developing the system rather than using it, and sometimes our notion
> of what is useful or acceptable is distorted because of it. Moreover,
> none of us are so smart that we can't be wrong, so a gut check from
> somebody else is often helpful.

> But, of course, an opinion that
> proceeds from a false premise doesn't provide useful guidance.

​
This is true - though I'd suspect not absolute.​

> Many
> people realize this, which is why we tend to get entirely too many
> opinions on questions like "should we change the version number?" and
> far too few on questions like "how should we refactor heap_update?".
>
>
​This is a non-sequitur - or I'm just to worn to follow it.

I did not intentionally set out to spend an hour of my own time to waste 20
minutes of yours. I won't apologize for an earnest attempt at
self-education and contribution; no matter how badly it turned out. I will
endeavor to learn from it and avoid similar errors in the future.

David J.