Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jeremy Schneider <schneider(at)ardentperf(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, satyanarlapuram(at)gmail(dot)com, marvin_liang(at)qq(dot)com, actyzhang(at)outlook(dot)com, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Date: 2021-10-06 00:43:10
Message-ID: 20211006004310.GE24555@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> On 10/5/21 15:07, Bruce Momjian wrote:
> > On Wed, Sep 8, 2021 at 07:18:08PM +0530, Bharath Rupireddy wrote:
> >> While working on one of the internal features, we found that it is a
> >> bit difficult to run pg_waldump for a normal user to know WAL info and
> >> stats of a running postgres database instance in the cloud. Many a
> >> times users or DBAs or developers would want to get and analyze
> >> following:
> >
> > Uh, are we going to implement everything that is only available at the
> > command line as an extension just for people who are using managed cloud
> > services where the command line is not available and the cloud provider
> > has not made that information accessible? Seems like this might lead to
> > a lot of duplicated effort.
>
> No. For most command line utilities, there's no reason to expose them in
> SQL or they already are exposed in SQL. For example, everything in
> pg_controldata is already available via SQL functions.

That's a good example.

> Specifically exposing pg_waldump functionality in SQL could speed up
> finding bugs in the PG logical replication code. We found and fixed a
> few over this past year, but there are more lurking out there.

Uh, why is pg_waldump more important than other command line tool
information?

> Having the extension in core is actually the only way to avoid
> duplicated effort, by having shared code which the pg_dump binary and
> the extension both wrap or call.

Uh, aren't you duplicating code by having pg_waldump as a command-line
tool and an extension?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-10-06 01:23:08 Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?
Previous Message Bruce Momjian 2021-10-06 00:38:51 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats