Re: bt_index_parent_check and concurrently build indexes

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Donghang Lin <donghanglin(at)gmail(dot)com>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Subject: Re: bt_index_parent_check and concurrently build indexes
Date: 2025-12-07 21:14:54
Message-ID: 202512072108.wwekoxhxa2xm@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Dec-06, Donghang Lin wrote:

> The issue itself in fact doesn't depend on BtreeCheckState's snapshot
> member. So the fix for 14-16 can make snapshot a local variable in
> the bt_check_every_level function to make the scope small. Do you
> think it's worth changing it to a local variable?

Ah, excellent observation. Yes, it's definitely worth it.

> I don't think the issue itself is related to 5ae2087202af but actually
> 7f563c09f890 where the heapallindexed flag is introduced for
> bt_index_check.

Hmm, interesting. I wonder what made me think it was about uniqueness.

> The committed test also doesn't check the uniqueness of an index.
> Should the commit message be restated to reflect this and also restate
> it's backport to 14 and up?

Sure.

> I think we'll have another chance to reflect that the issue is since
> 7f563c09f890 but not 5ae2087202af in master for this fix. I can give
> it a try.

Go ahead.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Tom: There seems to be something broken here.
Teodor: I'm in sackcloth and ashes... Fixed.
http://postgr.es/m/482D1632.8010507@sigaev.ru

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-12-07 22:09:37 Re: Fix incorrect comments in tuplesort.c
Previous Message Álvaro Herrera 2025-12-07 21:07:45 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY