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.
You can observe this by hacking it up like this:
smgrextend(SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum,
char *buffer, bool skipFsync)
{
+ if (blocknum > smgrnblocks(reln, forknum) + 1)
+ elog(INFO, "XXX");
+
smgrsw[reln->smgr_which].smgr_extend(reln, forknum, blocknum,
buffer, skipFsync);
Then you will get various test "failures" for hash indexes.
If you hack it up even further and actively fill the skipped-over blocks
with something other than zeros, you will get even more dramatic failures.
So apparently, this behavior is actively being used.
Maybe it was never meant that way and only works accidentally? Maybe
hash indexes are broken?