Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#425 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み PR（30日）
25

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ExtendDB/extenddb のほかの issue

ExtendDB/extenddb の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。