Horton

Re: logical replication of truncate command with trigger causes Assert

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Simon Riggs <simon.riggs@enterprisedb.com>
Date: 2021-06-12T18:43:08Z
Lists: pgsql-hackers 
On 2021-Jun-12, Tom Lane wrote:

> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Fri, Jun 11, 2021 at 8:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
> 
> Done that way.

Good call, thanks.  Not only it's not very useful to translate such
messages, but it's also quite a burden because some of them are
difficult to translate.

-- 
Álvaro Herrera       Valdivia, Chile
"Tiene valor aquel que admite que es un cobarde" (Fernandel)

Commits

  1. Don't use Asserts to check for violations of replication protocol.

  2. Rearrange logrep worker's snapshot handling some more.

  3. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.

  4. Logical replication support for TRUNCATE

  5. Logical replication support for initial data copy