On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> I am inclined to fix this by decrementing md_num_open_segs before modifying
> md_seg_fds (second attachment).
That leaked memory, since _fdvec_resize() assumes md_num_open_segs is also the
allocated array length. The alternative is looking better:
> An alternative would be to call
> _fdvec_resize() after every FileClose(), like mdtruncate() does; however, the
> repalloc() overhead could be noticeable. (mdclose() is called much more
> frequently than mdtruncate().)
I can skip repalloc() when the array length decreases, to assuage mdclose()'s
worry. In the mdclose() case, the final _fdvec_resize(reln, fork, 0) will
still pfree() the array. Array elements that mdtruncate() frees today will
instead persist to end of transaction. That is okay, since mdtruncate()
crossing more than one segment boundary is fairly infrequent. For it to
happen, you must either create a >2G relation and then TRUNCATE it in the same
transaction, or VACUUM must find >1-2G of unused space at the end of the
relation. I'm now inclined to do it that way, attached.