| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Chao Li <li(dot)evan(dot)chao(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 16:04:00 |
| Message-ID: | CALj2ACWwxTjGiyZgiunzjO3+HRrHG697uagOEvJunSCWqV+-VQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Oct 27, 2026 at 10:57 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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..
Thanks both for pointing me to the text_length() optimization.
> 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().
Nice, this is better. I think this approach makes the
define-index-before-set-valid injection point redundant. I haven't dug
into it, but maybe reindex-conc-index-built and
reindex-relation-concurrently-before-{swap, set-dead, drop} too, since
they all seem to be before a wait for lockers or older snapshots.
> So I am feeling pretty confident that I got that right. The buildfarm
> will judge, so we'll see. The CI was stable.
BF looks fine so far.
> Anyway, applied the patch down to v14, with the test down to v17.
Thanks for taking care of this.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ethantran | 2026-10-28 16:11:20 | Review: Price hashed aggregation for hash tables that exceed CPU cache capacity |
| Previous Message | Greg Burd | 2026-10-28 16:00:11 | Re: Quickselect instead of a heap for ORDER BY ... LIMIT N large bounded sorts |