Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Marko Tiikkaja <marko(at)joh(dot)to>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Fletcher <andy(at)prestigedigital(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Date: 2018-09-02 18:55:20
Message-ID: 15719.1535914520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> Tom, do you have input on this? Is it okay to backpatch this fix?

Well,

>> + * Treat window functions as parallel-restricted as the row ordering
>> + * induced by them is non-deterministic. We can relax this condition for
>> + * cases where the row ordering can be deterministic like when there is
>> + * an ORDER BY on the primary key, but those cases don't seem to be
>> + * interesting enough to have additional checks.

This comment seems fairly confused. I'd say something like

* Treat window functions as parallel-restricted because we aren't sure
* whether the input row ordering is fully deterministic, and the output
* of window functions might vary across workers if not. (In some cases,
* like where the window frame orders by a primary key, we could relax
* this restriction. But it doesn't currently seem worth expending extra
* effort to do so.)

>> In addition to the above, I have marked all built-in window functions
>> as parallel-restricted. I think even if we don't do that something
>> like above check should be sufficient, but OTOH, I don't see any
>> reason to keep the marking of such functions as parallel-safe. Is
>> there a reason, why we shouldn't mark them as parallel-restricted?

I am *strongly* against this. It's unnecessary catalog churn that we
might need to undo someday, and it confuses a property of the window
function infrastructure with a property of individual window functions.
As a counterexample, if a window function were parallel-unsafe for
some reason, we'd surely need to honor that. More realistically,
someone might add a window function that actually needs to be
parallel-restricted for reasons of its own, but then there would be
no obvious distinction between such a function and one that you'd
hacked up to be marked parallel-restricted even though it's safe in
itself. If we then do make the sort of optimization suggested in the
comment, it's likely that someone would just s/r/s/g for all the window
functions and thereby break such a function. Better to retain the
correct per-function markings.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-09-02 22:31:04 Re: Two constraints with the same name not always allowed
Previous Message Tom Lane 2018-09-02 18:15:42 Re: Two constraints with the same name not always allowed