Re: Make GiST waldump output more descriptive - Mailing list pgsql-hackers
| From | BharatDB |
|---|---|
| Subject | Re: Make GiST waldump output more descriptive |
| Date | |
| Msg-id | CAAh00ER=4q+abphts5XJbo0265piKjcgq5H=819=_wrZW2XSYQ@mail.gmail.com Whole thread Raw |
| In response to | Make GiST waldump output more descriptive (Kirill Reshke <reshkekirill@gmail.com>) |
| List | pgsql-hackers |
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
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
pgsql-hackers by date: