Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, saicharh(at)amazon(dot)com
Subject: Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY
Date: 2026-10-28 05:57:42
Message-ID: auGO1h6aVf5VaQCq@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 28, 2026 at 10:43:26AM +0900, Michael Paquier wrote:
> Ah. Good point here. Better to tweak that and remove the dependency
> on the length. Will look at all that head down..

+ CREATE FUNCTION wait_for_point(text) RETURNS void LANGUAGE plpgsql AS $$
+ BEGIN
+ LOOP
+ PERFORM 1 FROM pg_stat_activity WHERE wait_event = $1;
+ EXIT WHEN FOUND;
+ PERFORM pg_sleep(.1);
+ END LOOP;
+ END $$;

Hardcoded sleeps are my enemies because they can lead to longer tests
on fast machines in some cases. This also leads to a couple of
complications related to the two extra injection points you have been
using for the builds.

I have tested an extra approach where I make the REINDEX wait for
older snapshots after validating the new index, pointing at the fact
that these two extra injpoint wakeups should not be required, as much
as wait_for_point(). I have also confirmed with the same tweaks back
when I have debugged basic.spec, checking that this new test case was
safe. For example, using a hardcoded sleep inside injection_wait()
after the wait finishes to delay the shutdown of the session running
the wait, the test is longer, still stable..

So I am feeling pretty confident that I got that right. The buildfarm
will judge, so we'll see. The CI was stable.

Anyway, applied the patch down to v14, with the test down to v17.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-10-28 06:19:40 Re: multi-row INSERT broken with a sublink in a target column subscript
Previous Message Roman Khapov 2026-10-28 05:50:32 Re: kqueue backend for pgbench