Re: improving handling of FPIs during recovery prefetching

Hi Tomas, hi Shihao,

Thank you so much for working on this, Tomas. The series applies cleanly
to master and check-world passes. I also did a quick check with crash
recovery: pgbench scale 10, a CHECKPOINT, "UPDATE pgbench_accounts SET
abalance = abalance + 1 WHERE aid % 20 = 0", an immediate stop, then
recovery with recovery_prefetch = on. The posix_fadvise() calls dropped
from 23,502 on master to 821 with the series.

On 30.10.26 21:58, shihao zhong wrote:

> 1. There is no test for skip_fpi, so I attached a small TAP test.

Thanks for adding the test, Shihao. I checked the WAL from the TAP test
using pg_waldump and saw that the images aren't from the UPDATEs. The
cluster has data checksums enabled by default, and allows_streaming => 1
sets wal_log_hints to on. So, the first seqscan UPDATE on each table
writes an XLOG/FPI_FOR_HINT for every page of t and u, and the UPDATE
records don't have images.

When I set no_data_checksums => 1 and wal_log_hints = off, the images
move to the Heap/LOCK record written by the first update of each page,
as intended in the comments. But then the test fails: skip_fpi is 755,
since each page of t gets three more references (HOT_UPDATE, LOCK,
UPDATE+INIT) and each page of u one (HOT_UPDATE) while its image is
still pending. So, the skips are correct, but the bounds are not. Maybe
keep allows_streaming => 1, but add no_data_checksums => 1 and
wal_log_hints = off, and then check skip_fpi against a range derived
from the number of pages of t and u?

Best regards
Jan

--
Jan Nidzwetzki
PlanetScale