| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| 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:23:32 |
| Message-ID: | 1357803.1623252212@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>> On Jun 9, 2021, at 7:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Ugh, yeah. We should never be using Asserts to validate incoming
messages -- a test-and-elog is more appropriate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2021-06-09 15:28:20 | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options |
| Previous Message | Mark Dilger | 2021-06-09 15:14:25 | Re: logical replication of truncate command with trigger causes Assert |