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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: logical replication of truncate command with trigger causes Assert  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas
Дата:
Сообщение: Patch: Range Merge Join
Следующее
От: Tom Lane
Дата:
Сообщение: Re: logical replication of truncate command with trigger causes Assert