| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Reducing the chunk header sizes on all memory context types |
| Date: | 2022-08-29 15:57:45 |
| Message-ID: | 20220829155745.kndrwz6rlktjfhqq@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-08-29 11:43:14 -0400, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> > 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.
>
> Right, same conclusion I just came to. But it's not a "pre-existing"
> bug, because sizeof(SlabBlock) *was* maxaligned until David added
> another field to it.
>
> I think adding a padding field to SlabBlock would be a less messy
> solution than your patch.
That just seems to invite the same problem happening again later and it's
harder to ensure that the padding is correct across platforms.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-08-29 16:00:04 | Re: Reducing the chunk header sizes on all memory context types |
| Previous Message | Magnus Hagander | 2022-08-29 15:44:25 | Re: wal_sync_method=fsync_writethrough |