Re: Track in pg_replication_slots the reason why slots conflict?

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Track in pg_replication_slots the reason why slots conflict?
Дата
Msg-id CAA4eK1KoxFrEPnsDc9dg3jUwc0Vpu8zPFTvGLoNrnPZQX5i9zw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Track in pg_replication_slots the reason why slots conflict?  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Ответы Re: Track in pg_replication_slots the reason why slots conflict?  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Statistics Import and Export
Следующее
От: Richard Guo
Дата:
Сообщение: Re: Avoid computing ORDER BY junk columns unnecessarily