Hi,
On 2024-02-16 20:10:48 -0500, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> > On 2/17/24 00:14, Tom Lane wrote:
> >> The conclusion was that the specific invalid values didn't matter as
> >> much on the other platforms as they do with glibc. But right now you
> >> have a fifty-fifty chance that a pointer to garbage will look valid.
> >> Do we want to increase those odds?
>
> > Not sure. The ability to detect bogus pointers seems valuable, but is
> > the difference between 4/8 and 3/8 really qualitatively different? If it
> > is, maybe we should try to increase it by simply adding a bit.
>
> I think it'd be worth taking a fresh look at the bit allocation in the
> header word to see if we can squeeze another bit without too much
> pain. There's basically no remaining headroom in the current design,
> and it starts to seem like we want some.
I think we could fairly easily "move" some bits around, by restricting the
maximum size of a non-external chunk (i.e. allocations coming out of a larger
block, not a separate allocation). Right now we reserve 30 bits for the offset
from the block header to the allocation.
It seems unlikely that it's ever worth having an undivided 1GB block. Even if
we wanted something that large - say because we want to use 1GB huge pages to
back the block - we could just add a few block headers ever couple hundred
MBs.
Another avenue is that presumably the chunk<->block header offset always has
at least the two lower bits set to zero, so perhaps we could just shift
blockoffset right by two bits in MemoryChunkSetHdrMask() and left in
MemoryChunkGetBlock()?
> (I'm also wondering whether the palloc_aligned stuff should have been done
> some other way than by consuming a context type ID.)
Possibly, I just don't quite know how.
Greetings,
Andres Freund