On Wed, Jul 24, 2024 at 3:43 AM John Naylor <johncnaylo...@gmail.com> wrote: > > On Wed, Jul 24, 2024 at 5:40 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > Without MEMORY_CONTEXT_CHECK, if size is 16 bytes, required_size is > > also 16 bytes as it's already 8-byte aligned and Bump_CHUNKHDRSZ is 0. > > On the other hand with MEMORY_CONTEXT_CHECK, the requied_size is > > bumped to 40 bytes as chunk_size is 24 bytes and Bump_CHUNKHDRSZ is 16 > > bytes. Therefore, with MEMORY_CONTEXT_CHECK, we allocate more memory > > and use more Bump memory blocks, resulting in filling up TidStore in > > the test cases. We can easily reproduce this test failure with > > PostgreSQL server built without --enable-cassert. It seems that > > copperhead is the sole BF animal that doesn't use --enable-cassert but > > runs recovery-check. > > It seems we could force the bitmaps to be larger, and also reduce the > number of updated tuples by updating only the last few tuples (say > 5-10) by looking at the ctid's offset. This requires some trickery, > but I believe I've done it in the past by casting to text and > extracting with a regex. (I'm assuming the number of tuples updated is > more important than the number of tuples inserted on a newly created > table.)
Yes, the only thing that is important is having two rounds of index vacuuming and having one tuple with a value matching my cursor condition before the first index vacuum and one after. What do you mean update only the last few tuples though? - Melanie
