Re: Parallel INSERT (INTO ... SELECT ...)

On Thu, Feb 11, 2021 at 5:33 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> On Tue, Feb 9, 2021 at 1:04 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> >
> > * I think that the concerns raised by Tsunakawa-san in:
> >
> > https://www.postgresql.org/message-id/TYAPR01MB2990CCB6E24B10D35D28B949FEA30%40TYAPR01MB2990.jpnprd01.prod.outlook.com
> >
> > regarding how this interacts with plancache.c deserve a look.
> > Specifically, a plan that uses parallel insert may fail to be
> > invalidated when partitions are altered directly (that is without
> > altering their root parent). That would be because we are not adding
> > partition OIDs to PlannerGlobal.invalItems despite making a plan
> > that's based on checking their properties. See this (tested with all
> > patches applied!):
> >
>
> Does any current Postgres code add partition OIDs to
> PlannerGlobal.invalItems for a similar reason?
> I would have thought that, for example, partitions with a default
> column expression, using a function that is changed from SAFE to
> UNSAFE, would suffer the same plancache issue (for current parallel
> SELECT functionality) as we're talking about here - but so far I
> haven't seen any code handling this.
>
> (Currently invalItems seems to support PROCID and TYPEOID; relation
> OIDs seem to be handled through a different mechanism)..
> Can you elaborate on what you believe is required here, so that the
> partition OID dependency is registered and the altered partition
> results in the plan being invalidated?
> Thanks in advance for any help you can provide here.
>

Actually, I tried adding the following in the loop that checks the
parallel-safety of each partition and it seemed to work:

glob->relationOids =
lappend_oid(glob->relationOids, pdesc->oids[i]);

Can you confirm, is that what you were referring to?
(note that I've already updated the code to use
CreatePartitionDirectory() and PartitionDirectoryLookup())

Regards,
Greg Nancarrow
Fujitsu Australia