Re: Segfault on logical replication to partitioned table with foreign children - Mailing list pgsql-hackers

From Ilya Gladyshev
Subject Re: Segfault on logical replication to partitioned table with foreign children
Date
Msg-id 83d682e61ee79925db600bbbd9f62182471f49b4.camel@gmail.com
Whole thread Raw
In response to Re: Segfault on logical replication to partitioned table with foreign children  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2022-11-02 at 12:37 -0400, Tom Lane wrote:
> Since we're getting pretty close to the next set of back-branch
> releases,
> I went ahead and pushed a minimal fix along the lines suggested by
> Shi Yu.
> (I realized that there's a second ExecFindPartition call in worker.c
> that
> also needs a check.)  We still can at leisure think about refactoring
> CheckSubscriptionRelkind to avoid unnecessary lookups.  I think that
> is something we should do only in HEAD; it'll just be a marginal
> savings,
> not worth the risks of API changes in stable branches.  The other
> loose
> end is whether to worry about a regression test case.  I'm inclined
> not
> to bother.  The only thing that isn't getting exercised is the actual
> ereport, which probably isn't in great need of routine testing.
> 
>                         regards, tom lane

I agree that early checks limit some of the functionality that was
available before, so I guess the only way to preserve it is to do only
the last-minute checks after routing, fair enough. As for the
refactoring of the premature lookup, I have done some work on that in
the previous patch, I think we can just use it. Attached a separate
patch with the refactoring.

Attachment

pgsql-hackers by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: [PATCH] Add native windows on arm64 support
Next
From: John Naylor
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans