Re: Add contrib/pg_logicalsnapinspect

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add contrib/pg_logicalsnapinspect
Date: 2024-09-11 10:51:38
Message-ID: ZuF2Okt7aBR//bxu@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Sep 11, 2024 at 10:30:37AM +0530, Amit Kapila wrote:
> On Tue, Sep 10, 2024 at 8:56 PM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
> > On Mon, Sep 09, 2024 at 04:24:09PM +0530, Amit Kapila wrote:
> > > On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot
> > > <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> > > > as we decided not to expose the SnapBuildOnDisk and SnapBuild structs to public
> > > > and to create/expose 2 new functions in snapbuild.c then the functions in the
> > > > module would do nothing but expose the data coming from the snapbuild.c's
> > > > functions (get the tuple and send it to the client). That sounds weird to me to
> > > > create a module that would "only" do so, that's why I thought that in core
> > > > functions taking care of everything make more sense.
> > > >
> > >
> > > I see your point. Does anyone else have an opinion on the need for
> > > these functions and whether to expose them from a contrib module or
> > > have them as core functions?
> >
> > I looked at when the SNAPBUILD_VERSION has been changed:
> >
> > ec5896aed3 (2014)
> > a975ff4980 (2021)
> > 8bdb1332eb (2021)
> > 7f13ac8123 (2022)
> > bb19b70081 (2024)
> >
> > So it's not like we are changing the SnapBuildOnDisk or SnapBuild structs that
> > frequently. Furthermore, those structs are serialized and so we have to preserve
> > their on-disk compatibility (means we can change them only in a major release
> > if we need to).
> >
> > So, I think it would not be that much of an issue to expose those structs and
> > create a new contrib module (as v1 did propose) instead of in core new functions.
> >
> > If we want to insist that external modules "should" not rely on those structs then
> > we could put them into a new internal_snapbuild.h file (instead of snapbuild.h
> > as proposed in v1).
> >
>
> Adding snapbuild_internal.h sounds like a good idea.

Thanks for the feedback!

> > At the end, I think that creating a contrib module and exposing those structs in
> > internal_snapbuild.h make more sense (as compared to in core functions).
> >
>
> Fail enough. We can keep the module name as logicalinspect so that we
> can extend it for other logical decoding/replication-related files in
> the future.

Yeah, good idea. Done that way in v3 attached.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v3-0001-Add-contrib-pg_logicalinspect.patch text/x-diff 43.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2024-09-11 11:19:02 Make pg_stat_io view count IOs as bytes instead of blocks
Previous Message Rafia Sabih 2024-09-11 10:24:49 Re: Trim the heap free memory