On Wed, Aug 10, 2022 at 5:00 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > On Tue, Aug 09, 2022 at 01:21:41PM +0700, John Naylor wrote: > > I decided I wasn't quite comfortable changing snapshot handling > > without further guarantees. To this end, 0002 in the attached v11 is > > an addendum that adds assert checking (also pgindent and some > > comment-smithing). As I suspected, make check-world passes even with > > purposefully screwed-up coding. 0003 uses pg_lfind32 in syscache.c and > > I verified that sticking in the wrong answer will lead to a crash in > > assert-enabled builds in short order. I'd kind of like to throw this > > (or something else suitable) at the build farm first for that reason. > > It's simpler than the qsort/qunique/binary search that was there > > before, so that's nice, but I've not tried to test performance. > > Your adjustments in 0002 seem reasonable to me. I think it makes sense to > ensure there is test coverage for pg_lfind32(), but I don't know if that > syscache code is the right choice. For non-USE_SSE2 builds, it might make > these lookups more expensive.
I think that for non-USE_SSE2 builds, there is no additional overhead as all assertion-related code in pg_lfind32 depends on USE_SSE2. > I'll look around to see if there are any > other suitable candidates. As you proposed, having a test module for that seems to be a good idea. We can add test codes for future optimizations that utilize SIMD operations. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/