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
