On Thu, Feb 11, 2021 at 5:33 PM Greg Nancarrow <gregn4...@gmail.com> wrote: > > On Tue, Feb 9, 2021 at 1:04 AM Amit Langote <amitlangot...@gmail.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