Horton

Thread

  1. Make GiST waldump output more descriptive

    Kirill Reshke <reshkekirill@gmail.com> — 2025-10-06T05:22:31Z

    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

  2. Re: Make GiST waldump output more descriptive

    BharatDB <bharatdbpg@gmail.com> — 2025-10-28T07:13:35Z

    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@gmail.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
>