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
|
Список | 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 по дате отправления: