I wrote:
> I'm also wondering a bit whether there's anyplace *else* that is
> cheating by assuming that a downsizing repalloc doesn't move the block.
> We could investigate that by testing with a modified form of
> AllocSetRealloc that always moves the block, but of course that won't
> find bugs in untested code paths. So another possibility is to revert
> c477f3e44 and then document that AllocSetRealloc does not move a block
> when reducing its size. That does not seem very attractive though.
I did that testing, and found that check-world does not expose any other
trouble spots beyond the one in enlarge_list(). So I think this option
should be rejected.
That leaves us with needing to decide whether we should or shouldn't
forcibly split off the initial ListCell array if it's large. I'm
kind of leaning to not doing so, because doing that would add an
extra test (at least) to each list creation, and the frequency of
being able to reclaim space seems like it'd be pretty small. You
need a large initial list, *plus* a request to make it even larger.
(I haven't been able to reproduce skink's failure though, so maybe
there's something I'm missing.)
Thoughts?
regards, tom lane
