Re: Add contrib/pg_logicalsnapinspect
От | Amit Kapila |
---|---|
Тема | Re: Add contrib/pg_logicalsnapinspect |
Дата | |
Msg-id | CAA4eK1JHxtgYf+cgDsaX+zycZwvk1G-y=dqQ-P9c+9EhdS1Frg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add contrib/pg_logicalsnapinspect (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Add contrib/pg_logicalsnapinspect
|
Список | 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 по дате отправления: