Re: [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock) - Mailing list pgsql-hackers

From solai v
Subject Re: [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock)
Date
Msg-id CAF0whuce3Y8ubVcS5z+d+HrOH4VkxSxrAAOsaqq_==6O5+MpYw@mail.gmail.com
Whole thread
In response to Re: [SP-]GiST IOS visibility bug (was: Why doens't GiST require super-exclusive lock)  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
I tested the v02 patch series.
The patches applied cleanly and PostgreSQL built successfully.
I created a GiST index and verified that the query uses an Index Only
Scan (Heap Fetches: 0). I also tried to reproduce the reported race
condition by running concurrent Index Only Scans together with DELETE
and VACUUM operations, but I wasn't able to reproduce the issue
manually. Since this is a timing-dependent race condition, that wasn't
too surprising.
After applying the patches, I rebuilt PostgreSQL and ran the test
suite. All 245 tests passed, including the new regression test added
by this patch, and I didn't notice any regressions during my testing.
Overall, the patch applied cleanly, built successfully, and my testing
didn't reveal any issues.

regards

solai



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Document wal_compression=on
Next
From: Feng Wu
Date:
Subject: [PATCH] Avoid internal error for invalid interval typmods