Re: logical replication of truncate command with trigger causes Assert

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Subject: Re: logical replication of truncate command with trigger causes Assert
Date: 2021-06-09 15:14:25
Message-ID: C6BE98EB-158D-4130-9E1C-C3DCFAE0A023@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jun 9, 2021, at 7:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Here's a draft patch for that. I decided the most sensible way to
> organize this is to pair the existing ensure_transaction() subroutine
> with a cleanup subroutine. Rather unimaginatively, perhaps, I renamed
> it to begin_transaction_step and named the cleanup end_transaction_step.
> (Better ideas welcome.)

Thanks! The regression test I posted earlier passes with this patch applied.

> Somewhat unrelated, but ... am I reading the code correctly that
> apply_handle_stream_start and related routines are using Asserts
> to check that the remote sent stream-control messages in the correct
> order? That seems many degrees short of acceptable.

Even if you weren't reading that correctly, this bit:

xid = pq_getmsgint(s, 4);

Assert(TransactionIdIsValid(xid));

simply asserts that the sending server didn't send an invalid subtransaction id.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-09 15:23:32 Re: logical replication of truncate command with trigger causes Assert
Previous Message Thomas 2021-06-09 15:05:35 Patch: Range Merge Join