Re: Segfault on logical replication to partitioned table with foreign children

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: ilya(dot)v(dot)gladyshev(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Segfault on logical replication to partitioned table with foreign children
Date: 2022-10-31 08:48:29
Message-ID: CAFiTN-vvqCQDvHSms2Dct+9W-UAr+coPZ7Gn6+KGBNNEdqqP+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 30, 2022 at 7:09 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> > Yes, this looks like a bug and your fix seems correct to me. It would
> > be nice to add a test case for this scenario.
>
> A test case doesn't seem that exciting to me. If we were trying to
> make it actually work, then yeah, but throwing an error isn't that
> useful to test. The code will be exercised by replication to a
> regular partitioned table (I assume we do have tests for that).

That's true, but we missed this case because of the absence of the
test case so I thought at least we can add it now to catch any future
bug in case of any behavior change.

> A completely different line of thought is that this doesn't seem
> like a terribly bulletproof fix, since children could get added to
> a partitioned table after we look. Maybe it'd be better to check
> the relkind at the last moment before we do something that depends
> on a child table being a relation.

+1

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2022-10-31 08:50:02 Re: Fast COPY FROM based on batch insert
Previous Message Peter Eisentraut 2022-10-31 08:47:05 Re: Expand palloc/pg_malloc API