On Mon, 6 Mar 2023 at 15:40, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Thu, Mar 2, 2023 at 9:47 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> > > However, I am mainly looking for feedback about whether or not others
> > > would find this useful, and, if so, what columns they would like to see
> > > in the returned tuplestore.
>
> IMO, pg_get_wal_records_extended_info as proposed doesn't look good to
> me as it outputs most of the columns that are already given by
> pg_get_wal_records_info.What I think the best way at this point is to
> make it return the following:
> lsn pg_lsn
> block_id int8
> spcOid oid
> dbOid oid
> relNumber oid
> forkNames text
> fpi bytea
> fpi_info text
Wouldn't it be more useful to have
type PgXlogRecordBlock
( block_id int
...
, blockimage bytea
, data bytea
)
type PgXlogRecord
( start lsn
, ...
, blocks PgXlogRecordBlock[] -- array of record's registered blocks,
c.q. DecodedBkpBlock->blocks
, main_data bytea
)
which is returned by one sql function, and then used and processed
(unnest()ed) in the relevant views? It would allow anyone to build
their own processing on pg_walinspect where they want or need it,
without us having to decide what the user wants, and without having to
associate blocks with the main xlog record data through the joining of
several (fairly expensive) xlog decoding passes.
The basic idea is to create a single entrypoint to all relevant data
from DecodedXLogRecord in SQL, not multiple.
Kind regards,
Matthias van de Meent
