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

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, Sergey Sargsyan <sergey(dot)sargsyan(dot)2001(at)gmail(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>
Subject: Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY
Date: 2026-10-23 09:55:31
Message-ID: atsskNfWTCSrAUnn@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Aug-03, Matthias van de Meent wrote:

> Here's my long-overdue review of this patchset. I've reviewed all but
> patch 0001, as I assume that patch to not get committed.

See
https://postgr.es/m/af3oWkvS9K83UqmK@alvherre.pgsql
wherein I proposed to add a PG_TEST_EXTRA variable that would be
something like
stress_concurrently=1
which runs the test for a short time (I used 6 seconds), or
stress_concurrently=0 to disable the test completely, or larger positive
integers to scale the test up in duration and number of tuples.

With that setup, we could have tests of this nature for all the
CONCURRENTLY operations, all controllable via the same mechanism.

I'm not really sure of the wisdom of this, but having a test that runs
in pretty much every buildfarm animal and on every test run makes sense
to me, with an easy mechanism to disable it when it gets bothersome
(valgrind, cache clobber, etc). We could have one or two specific
buildfarm members that would run them for longer.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
[…] indem ich in meinem Leben oft an euch gedacht, euch glücklich zu machen. Seyd es!
A menudo he pensado en vosotros, en haceros felices. ¡Sedlo, pues!
Heiligenstädter Testament, L. v. Beethoven, 1802
https://de.wikisource.org/wiki/Heiligenstädter_Testament

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-10-23 09:58:22 Re: Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c)
Previous Message Dean Rasheed 2026-10-23 09:00:29 Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan