Hi Peipei, Bharath, I do not think this patch can reach the goal it states.
The goal is to remove all-zero pages from relation extension, so that an all-zero page means corruption. But smgrzeroextend() is the function that creates all-zero pages. Sending more code through it cannot reduce them, because FileZero gives you the same all-zero page that a sparse hole gives you. The main extension path also creates them on purpose. ExtendBufferedRelShared() calls smgrzeroextend(), and the comment just above it says we do not need a checksum for all-zero pages. A page is all zeros until the access method calls PageInit(), and vacuum tests PageIsNew() because of that. An all-zero page is a normal state, which is why bufpage.c has to accept one. The gap you found is real, but closing it means changing that lifecycle, not changing which function writes the zeros. On the three hunks themselves. 1. bufmgr.c zero fills N blocks that the copy loop overwrites right after. That is the cost Bharath measured. 2. md.c has the same shape and can write a whole segment, 1 GB at the default, where today it writes 8 kB. 3. bulk_write.c changes nothing today. Every caller leaves a gap of at most one block, and at one block mdzeroextend() falls back to the same single write the current loop already does. From cleanup perspective, that change make sense. If the goal is instead that extension should reserve space, so a later write cannot fail when the disk is full, that is a stronger argument than the commit message makes, and worth stating on its own. Applies cleanly on 6e70bef24e4, and the suites pass here. Thanks, Shihao
