Re: logical replication of truncate command with trigger causes Assert
От | Mark Dilger |
---|---|
Тема | Re: logical replication of truncate command with trigger causes Assert |
Дата | |
Msg-id | C6BE98EB-158D-4130-9E1C-C3DCFAE0A023@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: logical replication of truncate command with trigger causes Assert (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: logical replication of truncate command with trigger causes Assert
Re: logical replication of truncate command with trigger causes Assert |
Список | pgsql-hackers |
> On Jun 9, 2021, at 7:52 AM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: