Horton

Re: bt_index_parent_check and concurrently build indexes

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Donghang Lin <donghanglin@gmail.com>
Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrey Borodin <amborodin86@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: 2025-12-07T21:14:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. amcheck: Fix snapshot usage in bt_index_parent_check

  2. Teach contrib/amcheck to check the unique constraint violation

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