Re: logical replication of truncate command with trigger causes Assert
От | Tom Lane |
---|---|
Тема | Re: logical replication of truncate command with trigger causes Assert |
Дата | |
Msg-id | 1250962.1623192946@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | logical replication of truncate command with trigger causes Assert (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: logical replication of truncate command with trigger causes Assert
|
Список | 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 по дате отправления: