On 2026-Mar-20, Mihail Nikalayeu wrote:
> Rebased.
Thanks. The test in 0001 is a bit on the slow side; should we make it
optional with PG_TEST_EXTRA? It's even slower than the slowest test in
pg_amcheck, which is already somewhat too long.
1/9 postgresql:setup / tmp_install OK 0.84s
2/9 postgresql:setup / install_test_files OK 0.05s
3/9 postgresql:setup / initdb_cache OK 1.26s
4/9 postgresql:pg_amcheck / pg_amcheck/001_basic OK 0.20s 9 subtests passed
5/9 postgresql:pg_amcheck / pg_amcheck/005_opclass_damage OK 4.53s 10 subtests passed
6/9 postgresql:pg_amcheck / pg_amcheck/002_nonesuch OK 5.00s 107 subtests passed
7/9 postgresql:pg_amcheck / pg_amcheck/004_verify_heapam OK 8.59s 32 subtests passed
8/9 postgresql:pg_amcheck / pg_amcheck/003_check OK 19.14s 75 subtests passed
9/9 postgresql:pg_amcheck / pg_amcheck/006_cic OK 26.74s 12 subtests passed
The last pgbench subtest mentions GIN in the test name but doesn't
actually run it. Do we care? Would it be good to make the table be
unlogged?
These 10ms sleeps look suspicious. Should they be shorter? Longer? Is
it better if they are longer, because they help provide better coverage;
or how did you choose that value? I think all-but-one backends will
complete all the 999 transactions in the first 10ms sleep that the one
backend running the CIC does. Am I right about this? Would it work to
have no sleeps at all? Maybe instead of doing 1000 transactions, we
should run pgbench for 5 second or so; this would run several thousand
transactions.
Or should we just consider the test as not-for-commit, and only a
development aid?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
