Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

storage-postgres: the data path assumes READ COMMITTED and does not pin it; put_create_race fails under a repeatable read default

Đang mở
  • Có gì không ổn?
#570 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
postgresql, rust
Lĩnh vực
database

Hướng nghiên cứu

Start with crates/storage-postgres/tests/put_create_race.rs and reproduce the failure using PostgreSQL configured with default_transaction_isolation='repeatable read'; compare with the default setting. Then trace pool creation in PostgresEngine::new and data path transaction starts, using backup_engine.rs and data/transactions.rs as examples of explicit isolation levels. Done when the race tests pass under both settings and the required isolation behavior is documented or enforced.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

backend:postgresql bug

Summary

The PostgreSQL backend's data path assumes READ COMMITTED and does not set it. On a server whose default_transaction_isolation is repeatable read, crates/storage-postgres/tests/put_create_race.rs fails 9 of 9 on main 744ea291 with Internal("error returned from database: could not serialize access due to concurrent update") (SQLSTATE 40001) from the put path, where a READ COMMITTED server passes all nine.

Measured 2026-10-25 on pgvector/pgvector:pg16 started with -c default_transaction_isolation='repeatable read'; the same tests pass on the same image with the default setting.

Cause

PostgresEngine::new builds both pools with PgPoolOptions::new().connect(...) and no isolation setting, and the data-path transactions open with pool.begin(). The setting is operator-reachable from the connection string (options=-c default_transaction_isolation=...), ALTER DATABASE, ALTER ROLE and postgresql.conf. The crate does pin a level where it wants one (begin_with("BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY") in backup_engine.rs and data/transactions.rs), and #569 pins READ COMMITTED on update_table's transaction, so the mechanism is there; the rest of the control plane and the data path inherit the default.

Under REPEATABLE READ the create-race retry (an INSERT ... ON CONFLICT loser re-reading the winner's row) and every SELECT ... FOR UPDATE after a prior statement in the same transaction see the first statement's snapshot, and a row committed after it raises 40001 instead of being re-read, which the engine answers as a 500.

Fix shape

Either pin READ COMMITTED once per connection (after_connect on the pool running SET default_transaction_isolation = 'read committed'), which covers every transaction the crate opens, or open each transaction with begin_with("BEGIN ISOLATION LEVEL READ COMMITTED"). The pool hook is one place; state in the operator docs that the backend requires it. A CI job variant that starts the container with repeatable read would pin it.

Ngôn ngữ chính
Rust
Star
517
Fork
60
Merge trung bình
2 ngày 23 giờ
Pull request đã merge (30 ngày)
25

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ExtendDB/extenddb

Tất cả issue của ExtendDB/extenddb

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.