Re: Make GiST waldump output more descriptive

Hi Kirill and pgsql-hackers,

I came across your patch proposal and decided to give v1 a try on
PostgreSQL 19devel . Applied it manually after a small drift issue with git
apply, rebuilt cleanly, and ran some tests with a GiST index on a point
column (15k inserts for splits + 7.5k deletes + updates + VACUUM FULL for
updates).

I tried your patch and got output exactly like your message says—super
descriptive and helpful for understanding GiST redo! For example:

PAGE_UPDATE (counts print perfectly, offsets skipped when ntodelete=0 as
expected): rmgr: Gist ... desc: PAGE_UPDATE ntodelete 0 ntoinsert 1, blkref
#0: rel 1663/5/16445 blk 0

PAGE_SPLIT (full fields + tuple adds per blk, from one of several splits):
rmgr: Gist ... desc: PAGE_SPLIT page_split: splits to 3 pages, origrlink
-1, origleaf T, orignsn: 0, markfollowright: T, blk data 1: adds 2 tuples,
blk data 2: adds 117 tuples, blk data 3: adds 69 tuples, blkref #1: rel
1663/5/16445 blk 0, blkref #2: ... blk 1, blkref #3: ... blk 2

It makes WAL dumps way easier to follow—no more guessing on deletions or
split balances. No issues here.

I'm looking for further ways if I can contribute anything—maybe testing on
PostGIS for geo GiST, more scenarios, or helping with a v2 rebase? Just say
the word—excited to help!

Best,

Lakshmi G

On Mon, Oct 6, 2025 at 10:52 AM Kirill Reshke <reshkekirill(at)gmail(dot)com>
wrote:

> Hi hackers!
>
> pageinspect and pg_waldump are among my most favorite postgresql
> tools. I do often use them for my work. Recently I was busy working
> with GiST internals, and spotted a few places in GiST pg_waldump which
> can be enhanced to make output more descriptive.
>
> These changes helped me a lot to understand how GiST redo works, so
> maybe they are indeed useful?
>
>
> Patch changes:
>
> 1) For XLOG_GIST_PAGE_UPDATE record, patch adds `delete offsets:`
> field which describes which offsets on page ought to be deleted by
> this walrecord (ntodelete from
> gistxlogPageUpdate + data block 0 data). I did not add anything about
> ntoinsert/
> tuples to insert from this walrecord because of two reasons. First,
> insert page offset is not included in the walrecord, since redo
> routine always inserts at the end of index page. Secondly, I do not
> see how to pretty-print tuple data in waldump (since without schema
> knowledge this is basically random bytes). So I decided not to print
> anything.
>
>
> example output:
> ```
> rmgr: Gist len (rec/tot): 106/ 106, tx: 0, lsn:
> 0/155CD1D8, prev 0/155CD190, desc: PAGE_UPDATE ntodelete 28 ntoinsert
> 0 delete offsets: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
> 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, blkref #0: rel
> 1663/16384/17020 blk 122
>
> ```
>
> 2)
> For the XLOG_GIST_PAGE_SPLIT record, I simply printed how many tuples
> are to be placed on each page after GiST split. I also printed all
> fields of gistxlogPageSplit (it used to display `npages` only).
>
> example output:
>
> ```
> rmgr: Gist len (rec/tot): 10902/ 10902, tx: 1019, lsn:
> 0/154CBE28, prev 0/154CBDC8, desc: PAGE_SPLIT page_split: splits to 6
> pages, origrlink 2, origleaf T, orignsn: 0, markfollowright: T, blk
> data 1: adds 5 tuples, blk data 2: adds 4 tuples, blk data 3: adds 3
> tuples, blk data 4: adds 2 tuples, blk data 5: adds 1 tuples, blk data
> 6: adds 1 tuples, blkref #1: rel 1663/16384/17020 blk 45, blkref #2:
> rel 1663/16384/17020 blk 108, blkref #3: rel 1663/16384/17020 blk 109,
> blkref #4: rel 1663/16384/17020 blk 110, blkref #5: rel
> 1663/16384/17020 blk 111, blkref #6: rel 1663/16384/17020 blk 112
> ```
>
> WHYT?
>
> --
> Best regards,
> Kirill Reshke
>