Repository navigation
Update README.md - #1
Merged
Merged
Conversation
update go get command
Member
Author
|
@ngaut @qiuyesuifeng |
Member
|
LGTM |
shenli
pushed a commit
that referenced
this pull request
Oct 15, 2015
Merge pull request from pingcap/tidb
Closed
tiancaiamao
pushed a commit
that referenced
this pull request
Jun 25, 2018
when 'only_full_group_by' is set in sql_mode, raise error for non-aggregated column in query without GROUP BY. mysql> create table t(a bigint, b bigint, c bigint); Query OK, 0 rows affected (0.02 sec) mysql> select a, max(b) from t; ERROR 1140 (42000): In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'dc_test.t.a'; this is incompatible with sql_mode=only_full_group_by
Closed
guoshouyan
pushed a commit
to guoshouyan/tidb
that referenced
this pull request
Mar 5, 2024
* cache schema version by timestamp * fix test * avoid recursive locking * address comment * optimize the code * fix 40740 * use the commit ts of the shcema diff as the timestamp of the schema * address comment * address comment * address comment * fix CI Signed-off-by: xhe <xw897002528@gmail.com> * fix CI Signed-off-by: xhe <xw897002528@gmail.com> * Update meta/meta.go * Update domain/domain.go * fix test --------- Signed-off-by: xhe <xw897002528@gmail.com> Co-authored-by: xhe <xw897002528@gmail.com> Co-authored-by: CbcWestwolf <1004626265@qq.com> fix wrong timestamp in schema cache address comment format Co-authored-by: Chen Ding <dingc05@gmail.com>
guoshouyan
pushed a commit
to guoshouyan/tidb
that referenced
this pull request
Mar 5, 2024
…ingcap#44856) (pingcap#46616) (pingcap#1) close pingcap#46540 Co-authored-by: lance6716 <lance6716@gmail.com>
zeminzhou
pushed a commit
to zeminzhou/tidb
that referenced
this pull request
May 28, 2024
Add client-go and coprocessor section
Merged
1 of 13 tasks
1 of 13 tasks
cfzjywxk
pushed a commit
that referenced
this pull request
Dec 4, 2025
* *: add basic support for shared lock Signed-off-by: zyguan <zhongyangguan@gmail.com> bump client-go Signed-off-by: zyguan <zhongyangguan@gmail.com> * Merge pull request #1 from you06/release-8.5-shared-lock *: add shared lock metrics --------- Signed-off-by: zyguan <zhongyangguan@gmail.com> Co-authored-by: you06 <you1474600@gmail.com>
3 of 13 tasks
1 of 13 tasks
1 of 13 tasks
1 of 13 tasks
4 of 13 tasks
2 tasks done
2 of 13 tasks
premal
referenced
this pull request
in 6si/tidb
May 4, 2026
Bug #4 — panic in PointGetPlan.AccessObject and LoadTableStats when a partitioned+sharded table is accessed by PK/index on UPDATE/DELETE. GetPartitionIdxByRow returns a flat shard index (partIdx*shardCnt+slot) which was used directly to index pi.Definitions (original partition count), causing index-out-of-range. Fix maps flat→logical via idx/ShardCnt before indexing the original PI for display (access_object.go, point_get_plan.go) and resolves to the physical shard ID for KV access (GetPhysID in executor). Bug #1 — PointGetPlan misroutes PK-only queries on sharded tables to the wrong shard because locateShard hashes a zero shard-key column value. Fix: decline to generate PointGetPlan when the predicate omits the shard key; queries like WHERE id=X fall back to a table scan covering all shards. Bug #3 — RANGE/HASH/KEY+shard tables with a shard-only filter always pruned to partition p0 because PartitionPruning called pruneShardKeyPartition directly (returning flat indices only in the first partition's range). Fix: use pruneShardedRangeOrHashDynamic which expands matched shard slots across all logical partitions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
premal
referenced
this pull request
in 6si/tidb
May 4, 2026
Adds 7 unit tests to shard_test.go covering the flatIdx arithmetic, shardForRow bounds safety, rebuildShards post-DROP-PARTITION, and PartitionExpr staleness detection. Tests run without a live cluster and directly exercise the 4×4 layout (4 partitions × 4 shards) that triggered the OOB panic in production (Bug #4). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
premal
referenced
this pull request
in 6si/tidb
May 4, 2026
…ath; add integration tests Also fixes a remaining instance of Bug #1: convertToPointGet in find_best_task.go (the cost-based optimizer's slow path) was creating PointGetPlan without checking whether the shard key was present in the access conditions. Without the shard key the physical shard cannot be determined, causing silent wrong-shard reads. Adds shardKeyInAccessConds helper and guard in convertToPointGet. The fast path (tryPointGetPlan in point_get_plan.go) was already fixed; this covers the slow path. Also adds pkg/table/tables/shard_integration_test.go with 25 test functions covering: §1 DDL CREATE, §2 DDL errors, §3 DML, §5 partition pruning, §8 metadata, §12 ALTER PARTITION, §14 unique key semantics, §15 composite shard key pruning, §16 Point_Get routing (Bug #1 regression), §19 transaction isolation, §21 online schema change. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 of 13 tasks
2 of 5 tasks
ngaut
added a commit
that referenced
this pull request
Jul 29, 2026
Two sites, one root cause. `detectSelectAgg`'s Rust twin asked whether a
select field IS an aggregate call, so `SELECT IF(1=1, COUNT(*), 0)` took the
non-aggregate path and the rewriter refused the aggregate node. And the
aggregate-build stage treated any non-aggregate field as a FIRST_ROW carrier
over the SOURCE row, so `SELECT AVG(a) / 2` failed the same way even once the
query was recognised.
Both now follow Go: detection is `has_aggregate_flag()` over the select
fields, HAVING and ORDER BY -- the flag Go's `ast.HasAggFlag` reads, which
deliberately stops at a subquery boundary -- and a field containing an
aggregate is hoisted and left as a post-aggregation expression, the slot a
hoisted window value and a correlated subquery already use. No new stage.
Widening the detection would have traded an ERROR for a wrong answer:
`SELECT id FROM t ORDER BY COUNT(*)` is Go's 3029, and on the old narrow
detection it failed by accident in the rewriter. So
`checkOnlyFullGroupByWithOutGroupClause`'s 3029 rule lands with it. Go
collects its `nonAggCols` before the WHERE-clause pinning, which is why
`SELECT id FROM ha WHERE id = 1 ORDER BY COUNT(v)` is 3029 too (captured) --
the test is over the select list with nothing pinned.
Captured from TiDB (testkit, pkg/executor) over
ha (id, v) = (1,10),(1,20),(2,30),(2,40),(3,50):
select if(1=1, count(*), 0) from ha [[5]]
select case when count(*) > 2 then 'many' else 'few' end from ha [[many]]
select avg(v) / 2, avg(v/id) from ha [[15.00000000 16.33333333]]
select count(*) + 1 from ha [[6]]
select id, count(*) * 2 from ha group by id [[1 4] [2 4] [3 2]]
select id, if(count(*) = 2, 'pair', 'other') from ha group by id
[[1 pair] [2 pair] [3 other]]
select concat(count(*), '-', sum(v)) from ha [[5-150]]
select -count(*) from ha [[-5]]
select sum(v) + count(*) from ha [[155]]
select coalesce(max(v), 0) from ha where id = 99 [[0]]
select count(*) from ha order by count(*) [[5]]
select id from ha order by count(*) desc
errno=3029 "[planner:3029]Expression #1 of ORDER BY contains aggregate
function and applies to the result of a non-aggregated query"
select id, count(*) from ha order by count(*) errno=3029 #1
select id from ha order by id, count(*) errno=3029 #2
select id from ha where id = 1 order by count(v) errno=3029 #1
set sql_mode = ''
select id from ha order by count(*) desc [[1]]
select id, count(*) from ha order by count(*) [[1 5]]
table_diff ratchet 40 -> 36.
STILL DIVERGING nearby, unchanged: `SELECT COUNT(*) AS c, c + 1` is Go's
8123 and this tier's "unresolved column reference" -- both fail, with the
wrong errno, and that alias-in-a-later-field resolution predates this work.
ngaut
added a commit
that referenced
this pull request
Aug 17, 2026
rpc.go's RPCClient, restated against this workspace's client trait: the same encoded coprocessor request the gRPC client carries to a real TiKV dispatches in-process instead, which is exactly Go's own trick of implementing client-go's interface over the embedded store. The read transport is generic over its client, and this type is now a valid instance of that parameter -- the node can hold a store with no network under it. The gRPC-only concerns answer as an in-process call honestly can: channel closes succeed as no-ops, liveness is always reachable, and the cancellation carrier is honored by construction because the call completes synchronously -- the same window Go's in-process dispatch has. The typed KV commands ride the handler directly, since this seam carries only the coprocessor body. The test is the final joint: an encoded request through the TRAIT, an encoded response back, decoded to the row a transaction committed. Sixty-five green, zero warnings. Gap #1 from running the binary is now closed at every layer below the node itself: transactions, wire protocol, timestamps, coprocessor parse and execution, and the client seam. What remains is the node HOLDING this client -- a tidb-server construction path that chooses the in-process store -- which is main.go's --store unistore arm, the next course.
dbsid
pushed a commit
that referenced
this pull request
Aug 22, 2026
The transcendental trig builtins called f64::sin/cos/tan, i.e. the system libm. TiDB's source of truth is Go's standard library, whose Cephes-derived implementations round differently by one ulp on ordinary inputs: cot(1) came out 0x...06 instead of Go's 0x...08, sin(pi) 1.2246467991473532e-16 instead of Go's ...515e-16, and the source-vector table itself had encoded the libm answers -- a test that consults our own libm proves internal consistency, exactly the property that cannot detect divergence from Go (the divergence sweep's shape #1). Transcribe Go src/math/{sin,tan,trig_reduce}.go line for line into math_fn/go_trig.rs (pure-Go bodies; amd64 has no arch fast path) and route SIN/COS/TAN/COT through it. Golden bit vectors in the new module's tests are generated from go run; the misaligned rows in tests/math.rs are corrected to the engine's true values.
ngaut
pushed a commit
that referenced
this pull request
Sep 19, 2026
…bvious fix is wrong Profiled the full TPC-C mix at 16 threads: __memmove is tied with finish_task_switch as the #1 hotspot (~8% of CPU), traced to Catalog::physical_kv_table_by_id deep-cloning the whole KvTable -- including staged_record_keys, a per-transaction Mutex<HashSet<Vec<u8>>> that only grows as a transaction writes -- on every point-get/scan construction, even for the common unpartitioned case where the clone's only consumer (restrict_read_to_partitions) never runs. No code change. Wrapping staged_record_keys in Arc (the same move already applied to columns/indexes) looks obvious but is wrong: it would let a transaction's copy-on-write clone of a table it just wrote to keep sharing the same underlying Mutex<HashSet> as every other concurrent transaction's snapshot of that table, leaking staged/uncommitted write keys across transaction boundaries. Documented the safe direction (Arc a table already private to this transaction; make_mut only in the partitioned branch) and why it needs TableEntry::Kv restructured to hold Arc<KvTable>, touching every match site project-wide plus 14+ call sites -- too large and correctness-sensitive to attempt without dedicated scoping. Tracked as task 69 for a future session. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SRu3D99cwL5U7a524L7MpL
Merged
1 of 12 tasks
1 of 13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
update go get command