Обсуждение: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY

Hello, everyone!

Rebased.

Rebased.

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/

Hello, Álvaro!

Thanks for looking into it.

> Or should we just consider the test as not-for-commit, and only a
> development aid?

Initially I thought so, but looks like it is possible to make it committable.

> The test in 0001 is a bit on the slow side; should we make it
> optional with PG_TEST_EXTRA?

I made *parameters* to be depended  on PG_TEST_EXTRA ~= stress. It is
possible to apply the same pattern for other stress tests too.

> 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?

Fixed, it has its own pgbench because it has its own gin_index_check.

> Would it be good to make the table be unlogged?

Good idea, done.

> 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?

It actually has enough time to do multiple CIC (I see it from the
log). I updated the test to random delay, for non-stress variants -
from 0 to 1, for stress - up to 10.

Also, fixed a few small styling issues + added additional fixes for
waiting for a snapshot to be restored by a parallel worker.

Best regards,
Mikhail.

Hello!

0) Rebased
1) Added REPEATABLE READ isolation level
2) Some GUGs for developers
3) Some small refactorings

Rebased +

1) extract duplicate key error reporting into _bt_report_duplicate()
2) limit heap fetches in the tuplesort fail-fast duplicate check to a
configurable percentage


Best regards,
Mikhail.

Some small fixes around.