Horton

Re: logical replication of truncate command with trigger causes Assert

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: 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-11T15:26:41Z
Lists: pgsql-hackers 
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.
Thoughts?

			regards, tom lane

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