Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row - Mailing list pgsql-hackers

I wrote:
> 3. I think it's highly likely that the new test case is not portable.
> In particular a machine with MAXALIGN 4 would be likely to put a
> different number of tuples per page, or do the page split differently
> so that the page with fewer index tuples isn't page 3.  Unfortunately
> I don't seem to have a working setup like that right at the moment
> to verify; but I'd counsel trying this inside a VM or something to
> see if it's actually likely to survive on the buildfarm.

I spun up a 32-bit VM, since that had been on my to-do list anyway,
and it looks like I was right:

diff -U3 /usr/home/tgl/pgsql/contrib/pageinspect/expected/btree.out
/usr/home/tgl/pgsql/contrib/pageinspect/results/btree.out
--- /usr/home/tgl/pgsql/contrib/pageinspect/expected/btree.out  2022-09-12 15:15:40.432135000 -0400
+++ /usr/home/tgl/pgsql/contrib/pageinspect/results/btree.out   2022-09-12 15:15:54.481549000 -0400
@@ -49,11 +49,11 @@
 -[ RECORD 1 ]-+-----
 blkno         | 1
 type          | l
-live_items    | 367
+live_items    | 458
 dead_items    | 0
-avg_item_size | 16
+avg_item_size | 12
 page_size     | 8192
-free_size     | 808
+free_size     | 820
 btpo_prev     | 0
 btpo_next     | 2
 btpo_level    | 0
@@ -61,11 +61,11 @@
... etc etc ...

            regards, tom lane