Hi Melanie,
> Thanks for the feedback and for doing that investigation. I changed
> the test to just check the VM contents across primary and standby with
> pg_visibilitymap_summary().
Thanks for v2 and for addressing all the points. Both patches apply cleanly
on master (8d87367b39e) and build without warnings.
I reran the same WAL measurements as before, with CREATE DATABASE ...
STRATEGY WAL_LOG on master vs v2 (the two test templates each have a
1M-row table with a btree index):
template
master v2
template1 (stock) 4549
kB 5733 kB
1M rows inserted, VACUUM FREEZE 113 MB 114 MB
same, after deleting 1/3 and updating 10%,
then VACUUM 79 MB
80 MB
With v1 the last case was 117 MB, so the regression is gone. The remaining
increase, mostly visible for template1, is the VM and FSM pages now being
logged in full, which is the fix itself.
For 0002, ALTER TABLE/INDEX ... SET TABLESPACE on the delete/update
table:
master v2
heap 89 MB 61 MB
btree index 22 MB 13 MB
The test passes fine on v2 and for master it fails as expected on "copied
table visibility map matches standby".
The standby shows f|f for all 45 blocks, where the primary shows t|t. It
compares per-block pg_visibility_map() output, which also covers the
check-every-block point from before.
A minor optional suggestion, isnt($primary_visibility_map, '', ...) only
checks that rows come back. If VACUUM (FREEZE) ever left the bits
unset, both nodes would show f|f and the test would pass without testing
anything. Checking that the primary has at least one
all-frozen page would guard against that.
Overall v2 looks good to me.
Regards,
Surya Poondla
