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.) As for lowering the limit, we've experimented with 256kB here: https://www.postgresql.org/message-id/canwcazzutvz3lsypauyqvzcezxz7qe+9ntnhgyzdtwxpul+...@mail.gmail.com As I mention there, going lower than that would need a small amount of reorganization in the radix tree. Not difficult -- the thing I'm concerned about is that we'd likely need to document a separate minimum for DSA, since that behaves strangely with 256kB and might not work at all lower than that.
