Re: logical replication of truncate command with trigger causes Assert

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: logical replication of truncate command with trigger causes Assert
Дата
Msg-id CAA4eK1KkSpzioy4RwuiyQb_CrQ2URHSPShHTAEPswr25gX0r9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical replication of truncate command with trigger causes Assert  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: logical replication of truncate command with trigger causes Assert  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jun 11, 2021 at 8:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Fri, Jun 11, 2021 at 12:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Another thing
> >> I'm wondering is how many of these messages really need to be
> >> translated.  We could use errmsg_internal and avoid burdening the
> >> translators, perhaps.
>
> > Not sure but I see all existing similar ereport calls don't use errmsg_internal.
>
> I was thinking maybe we could mark all these replication protocol
> violation errors non-translatable.  While we don't want to crash on a
> protocol violation, it shouldn't really be a user-facing case either.
>

I don't see any problem with that as these are not directly related to
any user operation. So, +1 for making these non-translatable.

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Darafei "Komяpa" Praliaskouski
Дата:
Сообщение: Re: Questions about support function and abbreviate
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command