Re: smgrzeroextend clarification

Hi,

On May 11, 2023 2:37:00 AM PDT, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>On 10.05.23 20:10, Andres Freund wrote:
>>> Moreover, the text "except the relation can be extended by multiple blocks
>>> at once and the added blocks will be filled with zeroes" doesn't make much
>>> sense as a differentiation, because smgrextend() does that as well.
>>
>> Hm? smgrextend() writes a single block, and it's filled with the caller
>> provided buffer.
>
>But there is nothing that says that the block written by smgrextend() has to be the one right after the last existing block. You can give it any block number, and it will write there, and the blocks in between that are skipped over will effectively be filled with zeros. This is because of the way the POSIX file system APIs work.

Sure, but that's pretty much independent of my changes. With the exception of, I believe, hash indexes we are quite careful to never leave holes in files. And not just for performance reasons - itd make it much more likely to encounter ENOSPC while writing back blocks. Being unable to checkpoint (because they fail due to ENOSPC), is quite nasty.

>Maybe it was never meant that way and only works accidentally? Maybe hash indexes are broken?

It's known behavior I think - but also quite bad. I think it got a good bit worse after WAL support for hash indexes went in. I think during replay we sometimes end up actually allocating the blocks one by one.

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.