Hi, On May 11, 2023 2:37:00 AM PDT, Peter Eisentraut <peter.eisentr...@enterprisedb.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.
