Once we decided to cancel the RC1, what about including SPARK-29450 (
https://github.com/apache/spark/pull/27209) into RC2?
SPARK-29450 was merged into master, and Xiao figured out it fixed a
regression, long lasting one (broken at 2.3.0). The link refers the PR for
2.4 branch.
Thanks,
Jungtaek L
Sure. Wenchen and Hyukjin.
I observed all of the above reported issues and have been waiting to
collect more information before cancelling RC1 vote.
The other stuff I've observed is that Marcelo and Sean also requested
reverting the existing commit.
- https://github.com/apache/spark/pull/24732 (s
If we go for RC2, we should include both:
https://github.com/apache/spark/pull/27210
https://github.com/apache/spark/pull/27184
just for the sake of being complete and making the maintenance simple.
2020년 1월 16일 (목) 오후 12:38, Wenchen Fan 님이 작성:
> Recently we merged several fixes to 2.4:
> http
Recently we merged several fixes to 2.4:
https://issues.apache.org/jira/browse/SPARK-30325 a driver hang issue
https://issues.apache.org/jira/browse/SPARK-30246 a memory leak issue
https://issues.apache.org/jira/browse/SPARK-29708 a correctness issue(for
a rarely used feature, so not merged t
So do we want to repurpose
SPARK-30510 as an SQL config refactor?
Alternatively, what’s the smallest step forward I can take to publicly
document partitionOverwriteMode (which was my impetus for looking into this
in the first place)?
2020년 1월 15일 (수) 오전 8:49, Hyukjin Kwon 님이 작성:
> Resending to t
+1
On Wed, 15 Jan 2020, 08:24 Takeshi Yamamuro, wrote:
> +1;
>
> I checked the links and materials, then I run the tests with
> `-Pyarn -Phadoop-2.7 -Phive -Phive-thriftserver -Pmesos -Pkubernetes
> -Psparkr`
> on macOS (Java 8).
> All the things look fine and I didn't see the error on my env
>
Resending to the dev list for archive purpose:
I think automatically creating a configuration page isn't a bad idea
because I think we deprecate and remove configurations which are not
created via .internal() in SQLConf anyway.
I already tried this automatic generation from the codes at SQL built
I think automatically creating a configuration page isn't a bad idea
because I think we deprecate and remove configurations which are not
created via .internal() in SQLConf anyway.
I already tried this automatic generation from the codes at SQL built-in
functions and I'm pretty sure we can do the