Re: Add contrib/pg_logicalsnapinspect - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Add contrib/pg_logicalsnapinspect
Date
Msg-id CAA4eK1JHxtgYf+cgDsaX+zycZwvk1G-y=dqQ-P9c+9EhdS1Frg@mail.gmail.com
Whole thread Raw
In response to Re: Add contrib/pg_logicalsnapinspect  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Add contrib/pg_logicalsnapinspect
List pgsql-hackers
On Thu, Aug 29, 2024 at 6:33 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> > Yeah that's fair. And now I'm wondering if we need an extra module. I think
> > we could "simply" expose 2 new functions in core, thoughts?
> >
> > > > What do you think? Did you have something else in mind?
> > > >
> > >
> > > On similar lines, we can also provide a function to get the slot's
> > > on-disk data.
> >
> > Yeah, having a way to expose the data from the disk makes fully sense to me.
> >
> > > IIRC, Bharath had previously proposed a tool to achieve
> > > the same. It is fine if we don't want to add that as part of this
> > > patch but I mentioned it because by having that we can have a set of
> > > functions to view logical decoding data.
> >
> > That's right. I think this one would be simply enough to expose one or two
> > functions in core too (and probably would not need an extra module).
>
> +1 for functions in core unless this extra module
> pg_logicalsnapinspect works as a tool to be helpful even when the
> server is down.
>

We have an example of pageinspect which provides low-level functions
to aid debugging. The proposal for these APIs also seems to fall in
the same category, so why go for the core for these functions?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Junwang Zhao
Date:
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?