Re: Track in pg_replication_slots the reason why slots conflict? - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Track in pg_replication_slots the reason why slots conflict?
Date
Msg-id CAA4eK1KoxFrEPnsDc9dg3jUwc0Vpu8zPFTvGLoNrnPZQX5i9zw@mail.gmail.com
Whole thread Raw
In response to Re: Track in pg_replication_slots the reason why slots conflict?  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Track in pg_replication_slots the reason why slots conflict?
List pgsql-hackers
On Thu, Dec 21, 2023 at 8:21 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote:
> > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund <andres@anarazel.de> wrote:
> > > I'm not entirely sure I understand the difference - just whether we add one
> > > new column or replace the existing 'conflicting' column? I can see arguments
> > > for either.
> > >
> >
> > Agreed. I think the argument against replacing the existing
> > 'conflicting' column is that there is a chance that it is being used
> > by some monitoring script which I guess shouldn't be a big deal to
> > change. So, if we don't see that as a problem, I would prefer to have
> > a single column with conflict reason where one of its values indicates
> > there is no conflict.
>
> +1
>

Does anyone else have a preference on whether to change the existing
column or add a new one?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Statistics Import and Export
Next
From: Richard Guo
Date:
Subject: Re: Avoid computing ORDER BY junk columns unnecessarily