| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | bharath(dot)rupireddyforpostgres(at)gmail(dot)com, michael(at)paquier(dot)xyz, melanieplageman(at)gmail(dot)com, boekewurm+postgres(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add pg_walinspect function with block info columns |
| Date: | 2023-03-20 23:51:19 |
| Message-ID: | CAH2-WznDNVcyNLUPYs0W6KtYLc0diZrCqaDC7bwWPg=WV+UYYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 20, 2023 at 4:34 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I agree. A little redundancy is better when the alternative is fragile
> code, and I'm pretty sure that that applies here -- there won't be
> very many duplicated lines, and the final code will be significantly
> clearer. There can be a comment about keeping GetWALRecordInfo and
> GetWALBlockInfo in sync.
The new pg_get_wal_block_info outputs columns in an order that doesn't
seem like the most useful possible order to me. This gives us another
reason to have separate GetWALRecordInfo and GetWALBlockInfo utility
functions rather than sharing logic for building output tuples.
Specifically, I think that pg_get_wal_block_info should ouput the
"primary key" columns first:
reltablespace, reldatabase, relfilenode, blockid, start_lsn, end_lsn
Next comes the columns that duplicate the columns output by
pg_get_wal_records_info, in the same order as they appear in
pg_get_wal_records_info. (Obviously this won't include block_ref).
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2023-03-21 00:00:25 | Re: Add pg_walinspect function with block info columns |
| Previous Message | Tom Lane | 2023-03-20 23:51:12 | Re: Save a few bytes in pg_attribute |