You've already forked mariadb-columnstore-engine
mirror of
https://github.com/mariadb-corporation/mariadb-columnstore-engine.git
synced 2026-10-23 21:49:05 +03:00
d784c6edf0
Both abort PrimProc under _GLIBCXX_DEBUG in std::pop_heap via
__glibcxx_requires_heap_pred; in release they silently produced
whatever pop_heap happened to return.
1) TupleAnnexStep::finalizeParallelOrderBy /
TupleAnnexStep::finalizeParallelOrderByDistinct:
CompareRule::revertRules() is called before draining each
per-thread SortingPQ, so the stored sequence is no longer a heap
w.r.t. the flipped comparator. Using top()/pop() after that is
undefined. Drain via the underlying container instead -- iteration
order is irrelevant, each row is re-inserted into finalPQ under
the new ordering (also turns an O(N log N) drain into O(N)).
Added ReservablePQ::container() accessor for that.
2) LimitedOrderBy::processRow: the evict-and-replace path overwrote
the backing buffer of orderByQueue.top() via copyRow() *before*
pop()ing, which broke the heap for the current comparator
(OrderByRow::operator< reads fData, which had just changed).
Reorder so we: snapshot the top, remove it from fDistinctMap under
the OLD key, pop() while the heap is still valid, only then copy
the new row in and re-insert. This also fixes a pre-existing
distinct-map mis-keying where erase() ran against the already
mutated buffer.
Observed on columnstore/future.{rbo_parallel_ces_tpch_q20,
query_accelerator} as abort() inside pop_heap during parallel ORDER BY
merge / LIMIT processing. After the fix the full future suite passes
in Debug (7/7).