Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

SQL backends: LSI Query orders items that share an index sort key differently from the service

未关闭
  • 哪里不对？
#425 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
postgresql, rust, sqlite
领域
database

调研方向

Start by reading order_by_columns in crates/storage-postgres/src/data/query_scan.rs and query_order_columns in crates/storage-sqlite/src/data/query_scan.rs, then run 366-probe.py against the service and ExtendDB. Measure LSI tie ordering for number and binary base sort keys and partitions with more than four tied items before choosing a rule. Done when forward and reverse results, page boundaries, and LastEvaluatedKey match the service.

由索引模型根据 Issue 内容生成。

描述

bug

Summary

On a local secondary index, when several items in one partition share the same index sort key value, ExtendDB orders them by the base table sort key in byte order. The service orders them differently, and two fresh tables gave the same order, so the order depends on the key values. Pages and LastEvaluatedKey follow each side's order, so a client paging an LSI partition with ties sees different page contents on ExtendDB than on the service.

Found while verifying the fix for #366, which keeps ExtendDB's current order unchanged; this is a separate, pre-existing divergence.

Measured against the service (2026-10-21, us-east-1)

Table with partition key pk, sort key sk, LSI on lsk. Partition p holds nine items; three groups share an lsk value. Insertion order of (sk, lsk): (t07,m) (t03,m) (T05,m) (t01,a) (t10,z) (t02,z) (t04,m) (_09,a) (t06,z).

Query on the LSI, pk = p, no limit, forward, shown as [lsk, sk]:

order
service (two fresh tables, identical) [a,_09] [a,t01] [m,t03] [m,t07] [m,t04] [m,T05] [z,t06] [z,t02] [z,t10]
ExtendDB, PostgreSQL and SQLite, main at ec81e9d4 [a,_09] [a,t01] [m,T05] [m,t03] [m,t04] [m,t07] [z,t02] [z,t06] [z,t10]

ScanIndexForward = false returns the exact mirror on both sides. With Limit set, page boundaries and LastEvaluatedKey ({lsk, pk, sk}) follow each side's order, so the second page of Limit 2 is [m,t03] [m,t07] on the service and [m,T05] [m,t03] on ExtendDB.

Within a group the service order is not byte order of sk (T05 t03 t04 t07) and not insertion order (t07 t03 T05 t04). Across groups the index sort key orders in byte order on both sides.

Expected

Items that share an LSI sort key value are returned in the order the service returns them, forward and reverse, with the same page boundaries.

Where

order_by_columns in crates/storage-postgres/src/data/query_scan.rs and query_order_columns in crates/storage-sqlite/src/data/query_scan.rs order an LSI query by (sk, base_sk) on main (and by (sk, base_pk, base_sk) after #366). The rule the service applies to ties has to be measured on more shapes before it can be implemented: the probe above used string base sort keys of mixed case; number and binary sort keys, and partitions with more than four tied items, have not been measured.

Probe

366-probe.py from the #366 work creates the table above and prints the forward and reverse order and the Limit 2, Limit 3 and Limit 1 page sequences; it runs against the service with no endpoint set and against an ExtendDB server with EXTENDDB_TEST_ENDPOINT set.

主要语言
Rust
星标
517
派生
60
平均合并
2 天 23 小时
30 天内合并 PR
25

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ExtendDB/extenddb 的其他 Issue

查看 ExtendDB/extenddb 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。