Re: Show various offset arrays for heap WAL records - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Show various offset arrays for heap WAL records
Date
Msg-id CAAKRu_YSMS8kYixjjFBSm0ErTY-+Kw2zZVExwm0b35TBXj3LoA@mail.gmail.com
Whole thread Raw
In response to Re: Show various offset arrays for heap WAL records  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Show various offset arrays for heap WAL records  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Mon, Mar 13, 2023 at 9:41 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Mar 13, 2023 at 4:01 PM Melanie Plageman <melanieplageman@gmail.com> wrote:
>
> > I have added detail to xl_btree_delete and xl_btree_vacuum. I have added
> > the updated/deleted target offset numbers and the updated tuples
> > metadata.
> >
> > I wondered if there was any reason to do xl_btree_dedup deduplication
> > intervals.
>
> No reason. It wouldn't be hard to cover xl_btree_dedup deduplication
> intervals -- each element is a page offset number, and a corresponding
> count of index tuples to merge together in the REDO routine. That's
> slightly different to anything else, but not in a way that seems like
> it requires very much additional effort.

I went to add dedup records and noticed that since the actual
BTDedupInterval struct is what is put in the xlog, I would need access
to that type from nbtdesc.c, however, including nbtree.h doesn't seem to
work because it includes files that cannot be included in frontend code.

I, of course, could make some local struct in nbtdesc.c which has an
OffsetNumber and a uint16, since the BTDedupInterval is pretty
straightforward, but that seems a bit annoying.
I'm probably missing something obvious, but is there a better way to do
this?

On another note, I've thought about how to include some example output
in docs, and, for example we could modify the example output in the
pgwalinspect docs which includes a PRUNE record already for
pg_get_wal_record_info() docs. We'd probably just want to keep it short.

- Melanie



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: SQL/JSON revisited
Next
From: Stephen Frost
Date:
Subject: Re: Moving forward with TDE