Re: Reducing the chunk header sizes on all memory context types
От | Tomas Vondra |
---|---|
Тема | Re: Reducing the chunk header sizes on all memory context types |
Дата | |
Msg-id | b2f03d6e-083c-b500-b71b-d0acb06abe38@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Reducing the chunk header sizes on all memory context types (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Reducing the chunk header sizes on all memory context types
|
Список | pgsql-hackers |
On 8/29/22 17:27, Tomas Vondra wrote: > ... > > I suspect it's a pre-existing bug in Slab allocator, because it does this: > > #define SlabBlockGetChunk(slab, block, idx) \ > ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ > + (idx * slab->fullChunkSize))) > > and SlabBlock is only 20B, i.e. not a multiple of 8B. Which would mean > that even if we allocate block and size the chunks carefully (with all > the MAXALIGN things), we ultimately slice the block incorrectly. > The attached patch seems to fix the issue for me - at least it seems like that. This probably will need to get backpatched, I guess. Maybe we should add an assert to MemoryChunkGetPointer to check alignment? > This would explain the 4B difference I reported before, I think. But I'm > just as astonished we got this far in the tests - regular regression > tests don't do much logical decoding, and we only use slab for changes, > but I see the failure in 006 test in src/test/recovery, so the first > five completed fine. > I got confused - the first 5 tests in src/test/recovery don't do any logical decoding, so it's not surprising it's the 006 that fails. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: