From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: Add pg_walinspect function with block info columns |
Date: | 2023-03-06 14:40:14 |
Message-ID: | CALj2ACW+w3zctYBbzhgH_SLOXkQcLHL4VmGtUYhkrGZUDpFpWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 2, 2023 at 9:47 PM Melanie Plageman
<melanieplageman(at)gmail(dot)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
So, there can be multiple columns for the same record LSN, which
means, essentially (lsn, block_id) can be a unique value for the row.
If a block has FPI, fpi and fpi_info are non-null, otherwise, nulls.
If needed, this output can be joined with pg_get_wal_records_info on
lsn, to get all the record level details.What do you think? Will this
serve your purpose?
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | tender wang | 2023-03-06 14:50:51 | Re: wrong results due to qual pushdown |
Previous Message | Jelte Fennema | 2023-03-06 14:35:47 | Re: [EXTERNAL] Re: Support load balancing in libpq |