Horton

Re: Track in pg_replication_slots the reason why slots conflict?

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, shveta malik <shveta.malik@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Date: 2023-12-22T02:50:25Z
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 →

  1. Track conflict_reason in pg_replication_slots.

On Fri, Dec 22, 2023 at 5:00 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Dec 21, 2023 at 07:26:56AM -0800, Andres Freund wrote:
> > On 2023-12-21 19:55:51 +0530, Amit Kapila wrote:
> >> We can return int2 value from the function pg_get_replication_slots()
> >> and then use that to display a string in the view
> >> pg_replication_slots.
> >
> > I strongly dislike that pattern. It just leads to complicated views - and
> > doesn't provide a single benefit that I am aware of. It's much bettter to
> > simply populate the text version in pg_get_replication_slots().
>
> I agree that this is a better integration in the view, and that's what
> I would do FWIW.
>
> Amit, how much of a problem would it be to do a text->enum mapping
> when synchronizing the slots from a primary to a standby?
>

There is no problem as such in that. We were trying to see if there is
a more convenient way but let's move by having cause as text from both
the function and view as that seems to be a preferred way.

-- 
With Regards,
Amit Kapila.