Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY

Mihail Nikalayeu <mihailnikalayeu@gmail.com>

From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Antonin Houska <ah@cybertec.at>, Sergey Sargsyan <sergey.sargsyan.2001@gmail.com>, Hannu Krosing <hannuk@google.com>
Date: 2026-03-21T23:50:00Z
Lists: pgsql-hackers

Attachments

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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Revert changes to CONCURRENTLY that "sped up" Xmin advance

  2. VACUUM: ignore indexing operations with CONCURRENTLY