Repository navigation
parser: add gitignore - #2
Merged
Merged
Conversation
parser.go and scanner.go are generated code.
|
Why not have a per repo one? |
Member
|
@xiang90 I agree. |
Member
|
LGTM |
1 similar comment
Member
|
LGTM |
bb7133
referenced
this pull request
in bb7133/tidb
Dec 2, 2018
bb7133
referenced
this pull request
in bb7133/tidb
Dec 6, 2018
bb7133
referenced
this pull request
in bb7133/tidb
Dec 24, 2018
bb7133
referenced
this pull request
in bb7133/tidb
Jan 17, 2019
coocood
added a commit
to coocood/tidb
that referenced
this pull request
Apr 14, 2019
Reminiscent
pushed a commit
to Reminiscent/tidb
that referenced
this pull request
Aug 11, 2019
add functions to solve the decimal expression
cartersz
pushed a commit
to cartersz/tidb
that referenced
this pull request
Sep 21, 2022
Fix chunk reuse bug
cartersz
pushed a commit
to cartersz/tidb
that referenced
this pull request
Sep 21, 2022
This reverts commit 632d861.
rebelice
pushed a commit
to rebelice/tidb
that referenced
this pull request
Nov 21, 2022
fix: double equal in password option
YangKeao
pushed a commit
to YangKeao/tidb
that referenced
this pull request
Dec 27, 2022
Merge from PingCAP Repo
ljun0712
pushed a commit
to ljun0712/tidb
that referenced
this pull request
Mar 1, 2023
1 of 12 tasks
rleungx
pushed a commit
to rleungx/tidb
that referenced
this pull request
Feb 26, 2024
* init * audit: init first version of audit log * audit: support log global rotate * audit: update log keys * audit: more common notify implement * audit: add record id * audit: rename some names * audit: default use normal log path * audit: add server ip info * audit: do some refine * audit: Add some log keys * audit: update some item format * audit: add stmt demo * audit: support redact * audit: fix bug * audit: update filter * audit: update filter * audit: check user * audit: update * update * audit: update * audit: fix bug * aduit: update * audit: update * update * update * audit: add filter unit test * fmt * Add tests for `tidb_audit_enabled` and `tidb_audit_log` * Add tests for `tidb_audit_log_max_size` and `tidb_audit_log_max_lifetime` * Add tests for `tidb_audit_log_reserved_*` * TODO: TestAuditLogRedact * Fininsh `TestAuditLogRedact` * Update (pingcap#1) * fix typo (pingcap#2) * Add `TRANSACTION` * rename sysvar * audit_log_create_filter, audit_log_remove_filter * finish function call and table test * test privilege * finish test for sysvar * TODO: TestConnectionEvenClass * update * audit: fix lint for audit log (pingcap#1) * audit: fix UT failure caused by the change of redact log (pingcap#3) * audit: use `t.TempDir()` to make test stable (pingcap#4) * audit: fix test failed for 7.1 * Add `OWNERS` file (pingcap#35) Co-authored-by: Chao Wang <cclcwangchao@hotmail.com> * audit: fix panic when logging sometime (pingcap#26) (pingcap#31) * test: fix unstable test TestAuditLogReservedDays (pingcap#8) * Format sysvar_test.go * audit: use `StatementContext` to generate redacted SQL (pingcap#9) * audit: fix panic when logging sometime (pingcap#26) * update * add owner * Update OWNERS --------- Co-authored-by: CbcWestwolf <1004626265@qq.com> Co-authored-by: wuhuizuo <wuhuizuo@126.com> * audit: fix panic sometimes when `create user` without password (pingcap#37) (pingcap#39) * This is an automated cherry-pick of pingcap#37 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> * fix conflict --------- Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Co-authored-by: 王超 <cclcwangchao@hotmail.com> * extension/audit: introduce serverless audit log Signed-off-by: Wen Jiazhi <jiazhi.wen@pingcap.com> * update bazel config Signed-off-by: Wen Jiazhi <jiazhi.wen@pingcap.com> * support enable audit log when activate Signed-off-by: Wen Jiazhi <jiazhi.wen@pingcap.com> * add gwconnid to audit log Signed-off-by: Wen Jiazhi <jiazhi.wen@pingcap.com> * comment unstable test * update bazel * add log about activate request * diff audit log enabled * audit: fix memory leak for executeSQL (pingcap#44) (pingcap#45) * This is an automated cherry-pick of pingcap#44 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> * Update util.go --------- Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Co-authored-by: 王超 <cclcwangchao@hotmail.com> * Update extension/serverless/OWNERS --------- Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io> Signed-off-by: Wen Jiazhi <jiazhi.wen@pingcap.com> Co-authored-by: Chao Wang <cclcwangchao@hotmail.com> Co-authored-by: cbcwestwolf <1004626265@qq.com> Co-authored-by: Ti Chi Robot <ti-community-prow-bot@tidb.io> Co-authored-by: wuhuizuo <wuhuizuo@126.com> Co-authored-by: zzm <zhouzemin@pingcap.com> Co-authored-by: Yuqing Bai <baiyuq@gmail.com>
guoshouyan
pushed a commit
to guoshouyan/tidb
that referenced
this pull request
Mar 5, 2024
Cherry-picking lightning 6.5.4
1 of 13 tasks
crazycs520
added a commit
that referenced
this pull request
Oct 13, 2025
…#2) This PR is for synchronizing the upstream master of TiDB with the feature/tidbx-on-v8.5.1 branch. Co-authored-by: crazycs520 <chenshuang@pingcap.cn> Co-authored-by: lance6716 <tianyuan@pingcap.cn> Co-authored-by: ZierZhao <zhaoyilin@pingcap.cn> Co-authored-by: Brahmamantra <2033552517@qq.com> Co-authored-by: VGalaxies <yuchen.ding@pingcap.cn> Co-authored-by: Z Fan <2033552517@qq.com> Co-authored-by: crazycs520 <crazycs520@gmail.com> Reviewed-on: https://git.pingcap.net/pingkai/tidb/pulls/2 Reviewed-by: crazycs520 <chenshuang@pingcap.cn> Co-authored-by: zhou fan <zhou.fan@pingcap.cn> Co-committed-by: zhou fan <zhou.fan@pingcap.cn>
1 of 13 tasks
4 of 13 tasks
2 tasks done
YuhaoZhang00
added a commit
to YuhaoZhang00/tidb
that referenced
this pull request
Apr 27, 2026
Move the per-RPC trace log line up to fire on the terminal (region
drained, range == nil) branch as well as the non-terminal paging path
that was already covered. Add a 'terminal' boolean so offline analysis
can distinguish the two:
- terminal=false → non-terminal paging RPC (region not yet drained).
Same population as the EMA training set below.
Whether each such RPC was capped by rows, time, or
bytes depends on tidb_paging_size_bytes — the log
does not care.
- terminal=true → TiKV's executor drained the region (scenario A
natural tail of a large region; scenario B a small
region scanned in one RPC). Previously not logged
at all, which left a >50%% sample blind spot vs PD's
paging_prediction_residual_bytes histogram.
The terminal signal is purely 'region drained', not 'byte budget hit',
so this fix applies uniformly to all paging modes including
tidb_paging_size_bytes=0 (rows/time-driven paging).
The region/lock retry path is intentionally still NOT logged: predicted
vs actual aren't comparable on a retry, and emitting them would only
muddy residual analysis.
The EMA Observe site stays where it is. Only non-terminal paging RPCs
feed the predictor, since they are the only sample class whose 'next of
the same kind' is well-defined within a (iter, region) sequence.
Including terminal samples in the EMA would pull predictions below the
typical mid-region size, under-charging the next non-terminal RPC at
pre-charge time and weakening tier protection.
Net effect: the log row set becomes a strict superset of the EMA
training set, with the EMA-comparable subset recoverable by filtering
terminal=false. This closes the observability blind spot (R7 follow-up
pingcap#2) where Grafana's PD-side residual histogram saw p50 ~= -14 MiB while
log analysis saw p50 ~= 0, the gap being entirely unlogged terminal
RPCs.
Signed-off-by: Yuhao Zhang <yhzhang00@outlook.com>
YuhaoZhang00
added a commit
to YuhaoZhang00/tidb
that referenced
this pull request
Apr 27, 2026
Move the per-RPC trace log line up to fire on the terminal (region
drained, range == nil) branch as well as the non-terminal paging path
that was already covered. Add a 'terminal' boolean so offline analysis
can distinguish the two:
- terminal=false → non-terminal paging RPC (region not yet drained).
Same population as the EMA training set below.
Whether each such RPC was capped by rows, time, or
bytes depends on tidb_paging_size_bytes — the log
does not care.
- terminal=true → TiKV's executor drained the region (scenario A
natural tail of a large region; scenario B a small
region scanned in one RPC). Previously not logged
at all, which left a >50%% sample blind spot vs PD's
paging_prediction_residual_bytes histogram.
The terminal signal is purely 'region drained', not 'byte budget hit',
so this fix applies uniformly to all paging modes including
tidb_paging_size_bytes=0 (rows/time-driven paging).
The region/lock retry path is intentionally still NOT logged: predicted
vs actual aren't comparable on a retry, and emitting them would only
muddy residual analysis.
The EMA Observe site stays where it is. Only non-terminal paging RPCs
feed the predictor, since they are the only sample class whose 'next of
the same kind' is well-defined within a (iter, region) sequence.
Including terminal samples in the EMA would pull predictions below the
typical mid-region size, under-charging the next non-terminal RPC at
pre-charge time and weakening tier protection.
Net effect: the log row set becomes a strict superset of the EMA
training set, with the EMA-comparable subset recoverable by filtering
terminal=false. This closes the observability blind spot (R7 follow-up
pingcap#2) where Grafana's PD-side residual histogram saw p50 ~= -14 MiB while
log analysis saw p50 ~= 0, the gap being entirely unlogged terminal
RPCs.
Signed-off-by: Yuhao Zhang <yhzhang00@outlook.com>
2 of 13 tasks
premal
referenced
this pull request
in 6si/tidb
May 4, 2026
EXPLAIN showed p2023_s0 for a 2024 date range query because PartitionPruning for RANGE+shard tables only did shard-slot pruning (all logical partitions survive) and returned flat index 0 (p2023_s0) when slot 0 matched. Fix: add pruneShardedRangeDynamic (dynamic mode) and processShardedRangePartition (static mode) — both perform two-stage pruning: 1. RANGE pruning on logical partitions via pruneRangePartition + original PI 2. Shard-slot pruning via pruneShardKeyPartition on flat PI 3. Intersect: surviving flat indices = partIdx*shardCnt + slot With this fix, EXPLAIN for `WHERE created_at BETWEEN 2024... AND company_id=42` correctly shows only p2024_s0 (or whichever slot company_id hashes to). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 of 13 tasks
takaidohigasi
referenced
this pull request
in takaidohigasi/tidb
May 17, 2026
Fixes for D3Hunter's review on pingcap#68028: [Blocker] Dual-password clauses are parsed but ignored by execution - Add executor stubs that reject RETAIN CURRENT PASSWORD / DISCARD OLD PASSWORD with ER_NOT_SUPPORTED_YET in executeAlterUser and executeSetPwd. Full execution / privilege / storage logic lives in the follow-up PR pingcap#68393. - Expose exeerrors.ErrNotSupportedYet for callers (was previously only available via dbterror.ClassExecutor.NewStd inline). - New TestDualPasswordParserOnlyStub in passwordtest to pin the stub's behavior. [Major #2] CREATE USER accepted dual-password clauses outside MySQL grammar - Drop the CreateUserSpec/CreateUserSpecList non-terminals and route CREATE USER back through the original UserSpec/UserSpecList chain. CREATE USER + RETAIN/DISCARD is now a parser-level syntax error, matching MySQL. [Major pingcap#3] ALTER USER over-accepted invalid RETAIN combinations - Introduce AuthOptionWithPassword (the BY-form subset of AuthOption) and restructure AlterUserSpec to bind RETAIN only to that subset. Reject at parse time: ALTER USER u IDENTIFIED WITH plugin AS '<hash>' RETAIN ... ALTER USER u IDENTIFIED WITH plugin RETAIN ... ALTER USER u RETAIN CURRENT PASSWORD (no auth) ALTER USER u IDENTIFIED BY '...' DISCARD OLD PASSWORD - DISCARD becomes its own AlterUserSpec variant (no auth-option coexists with it). [Major pingcap#4] Grammar label/documentation contradiction - Drop the misleading 'unsupported dual password option' label on the deleted CreateUserSpec; rewrite UserSpec/AlterUserSpec labels to state the contract accurately. [Major pingcap#5] Generic *PasswordOrLockOption type was overloaded - Introduce dedicated ast.DualPasswordOption and ast.DualPasswordOptionType (with DualPasswordRetainCurrent / DualPasswordDiscardOld). UserSpec.DualPasswordOption now uses the dedicated type. Remove the RetainCurrentPassword and DiscardOldPassword iota entries from PasswordOrLockOption. [Minor pingcap#6] ALTER USER USER() branch - USER() still does not route through AlterUserSpecList; dual-password on USER() is now a parse-time syntax error (covered by negative test). [Minor pingcap#7] Parser tests had no negative coverage - Add explicit ok=false rows for CREATE USER + RETAIN, the AS-hash + RETAIN form, bare RETAIN with no auth, plain BY + DISCARD, bare-plugin + RETAIN, and ALTER USER USER() + RETAIN. [Minor pingcap#8] CREATE/ALTER user-spec grammar duplication - Now naturally eliminated because CREATE USER reuses UserSpec. Behavior PR (pingcap#68393) needs to: - Remove the executor stubs added here. - Adopt the new ast.DualPasswordOption / DualPasswordOptionType symbols (the iota entries it currently consumes are gone). Ref pingcap#60587
2 of 5 tasks
takaidohigasi
referenced
this pull request
in takaidohigasi/tidb
Jun 3, 2026
…witch Code-review findings (recall pass): #2 (correctness): the dual-password secondary-password login fallback was unreachable when the primary authentication_string is empty, because the whole password-verification block was gated on `len(pwd) > 0`. After `ALTER USER u IDENTIFIED BY 'new' RETAIN CURRENT PASSWORD` followed by `ALTER USER u IDENTIFIED BY ''` (same plugin, no DISCARD), the row has an empty primary alongside a valid retained secondary, but the secondary could never authenticate. The branch now also enters when a non-empty additional_password exists, and skips the primary check for an empty primary so the secondary is still tried. pingcap#7 (altitude): the secondary-password check (`matchSecondary`) duplicated the per-plugin primary-auth switch and would drift as plugins/hash handling evolve. Extracted a single `checkPasswordForPlugin` helper used for BOTH the primary authentication_string and the retained secondary, so the two can never diverge. The historical, error-log-review-stable log lines (native "decode password string failed" warn; caching_sha2 Error) are preserved at the call site. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 of 13 tasks
mjonss
added a commit
to mjonss/tidb
that referenced
this pull request
Jun 28, 2026
…dmap pingcap#2) The accessors (ST_Latitude/ST_Longitude) already returned the first coordinate as the latitude (= MySQL), but the S2 covering and ST_Distance_Sphere treated the first coordinate as longitude (EncodePointS2(x,y), greatCircleMeters(x,y)) — internally inconsistent, so 4326 distances and distance-predicate result sets diverged from MySQL. Make the S2 key, the haversine, the cap centre, the lat/lng cover, and the cap bbox all use x=latitude, y=longitude. The index stays internally consistent (covering + refine + bbox all flipped together); ST_Distance_Sphere now matches MySQL. Verified vs running MySQL 9.7: ST_Latitude(POINT(30 50),4326)=30, ST_Longitude=50, ST_Distance_Sphere(POINT(30 50),POINT(31 51))=146775.88330371436 m (TestPOCSpatial4326Axis). Updated TestPOCSpatialS2 to the (lat,lng) WKT order. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mjonss
added a commit
to mjonss/tidb
that referenced
this pull request
Jun 28, 2026
…cap#2 axis flip GeoJSON (RFC 7946) is always [longitude, latitude], and MySQL honors that even though its 4326 WKT is (latitude, longitude). The roadmap-pingcap#2 axis fix made the POC store 4326 as (lat, lng) but did not touch GeoJSON I/O, which passes coordinates straight through simplefeatures — so ST_AsGeoJSON started emitting [lat, lng] (wrong vs MySVL and the RFC). Swap the axis for 4326 in ST_AsGeoJSON (output) and ST_GeomFromGeoJSON (input, always 4326), via geom.TransformXY; SRID-0 GeoJSON is unchanged. Validate 4326 bounds on GeoJSON input too. Verified vs MySQL 9.7: ST_AsGeoJSON(POINT(30 50),4326)=[50,30]; round-trip preserves lat 30 / lng 50 (TestPOCSpatial4326GeoJSONAxis). Caught by a review of the pingcap#2 fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Merged
1 of 12 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.
parser.go and scanner.go are generated code.