Re: Add contrib/pg_logicalsnapinspect
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: 2024-08-29T09:21:36Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix indentation issue
- b955df443405 18.0 cited
-
pg_logicalinspect: Stabilize isolation tests.
- a49927f04cd0 18.0 landed
-
Add contrib/pg_logicalinspect.
- 7cdfeee320e7 18.0 landed
-
Move SnapBuild and SnapBuildOnDisk structs to snapshot_internal.h.
- e2fd615ecc17 18.0 landed
On Wed, Aug 28, 2024 at 1:25 AM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > On Mon, Aug 26, 2024 at 07:05:27PM +0530, Amit Kapila wrote: > > On Thu, Aug 22, 2024 at 5:56 PM Bertrand Drouvot > > <bertranddrouvot.pg@gmail.com> wrote: > > > > > > 2. The SnapBuildOnDisk and SnapBuild structs are now exposed to public. Means > > > we should now pay much more attention when changing their contents but I think > > > it's worth it. > > > > > > > Is it possible to avoid exposing these structures? Can we expose some > > function from snapbuild.c that provides the required information? > > Yeah, that's an option if we don't want to expose those structs to public. > > I think we could 1/ create a function that would return a formed HeapTuple, or > 2/ we could create multiple functions (about 15) that would return the values > we are interested in. > > I think 2/ is fine as it would give more flexiblity (no need to retrieve a whole > tuple if one is interested to only one value). > True, but OTOH, each time we add a new field to these structures, a new function has to be exposed. I don't have a strong opinion on this but seeing current use cases, it seems okay to expose a single function. > 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. 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. -- With Regards, Amit Kapila.