Re: logical replication of truncate command with trigger causes Assert - Mailing list pgsql-hackers

From Tom Lane
Subject Re: logical replication of truncate command with trigger causes Assert
Date
Msg-id 1250962.1623192946@sss.pgh.pa.us
Whole thread Raw
In response to logical replication of truncate command with trigger causes Assert  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: logical replication of truncate command with trigger causes Assert
List pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.com> writes:
> On master, when a statement level trigger is fired for a replicated truncate command, the following stack trace is
generated:

Hmm.

> I believe the issue was introduced in commit 84f5c2908da which added EnsurePortalSnapshotExists.   That's not going
towork in the case of logical replication, because there isn't an ActivePortal nor a snapshot. 

The right way to say that is "commit 84f5c2908da exposed the pre-existing
unsafe behavior of this code".  It's not okay to run arbitrary user code
without holding a snapshot to protect TOAST dereference operations.

I suppose that either apply_dispatch or LogicalRepApplyLoop needs to
grow some more snapshot management logic, but I've not looked at that
code much, so I don't have an opinion on just where to add it.

There's a reasonable case to be made that running user code outside
a Portal is a just-plain-bad idea, so we should fix the logical
apply worker to make it create a suitable Portal.  I speculated about
that in the commit message for 84f5c2908da, but I don't feel like
taking point on such work.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Next
From: Justin Pryzby
Date:
Subject: Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)