Re: [PATCH] Refactor remaining zero-fill relation extensions to use smgrzeroextend()

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