Re: Add pg_walinspect function with block info columns - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add pg_walinspect function with block info columns
Date
Msg-id ZBTzlcTWpZP0txl7@paquier.xyz
Whole thread Raw
In response to Re: Add pg_walinspect function with block info columns  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Add pg_walinspect function with block info columns  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Fri, Mar 17, 2023 at 12:36:04PM -0700, Peter Geoghegan wrote:
> I think that this direction makes a lot of sense. Under this scheme,
> we still have pg_get_wal_records_info(), which is more or less an SQL
> interface to the information that pg_waldump presents by default.
> That's important when the record view of things is of primary
> importance. But now you also have a "block oriented" view of WAL
> presented by pg_get_wal_block_info(), which is useful when particular
> blocks are of primary interest. I think that I'll probably end up
> using both, while primarily using pg_get_wal_block_info() for more
> advanced analysis that focuses on what happened to particular blocks
> over time.

FWIW, I am not sure that it is a good idea and that we'd better not
encourage too much the use of block_info() across a large range of
WAL, which is what this function will make users eager to do in this
case as it is possible to apply directly more filters to it.  This is
a community, so, anyway, if you feel strongly about doing this change,
feel free to.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Should we remove vacuum_defer_cleanup_age?
Next
From: Michael Paquier
Date:
Subject: Re: Remove last traces of SCM credential auth from libpq?