Hi Alvaro, Thanks for looking at this one.
On Thu, Dec 1, 2022 at 3:12 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Looking at 0001, I wonder if we should have a crosscheck that a > PartitionPruneInfo you got from following an index is indeed constructed > for the relation that you think it is: previously, you were always sure > that the prune struct is for this node, because you followed a pointer > that was set up in the node itself. Now you only have an index, and you > have to trust that the index is correct. Yeah, a crosscheck sounds like a good idea. > I'm not sure how to implement this, or even if it's doable at all. > Keeping the OID of the partitioned table in the PartitionPruneInfo > struct is easy, but I don't know how to check it in ExecInitMergeAppend > and ExecInitAppend. Hmm, how about keeping the [Merge]Append's parent relation's RT index in the PartitionPruneInfo and passing it down to ExecInitPartitionPruning() from ExecInit[Merge]Append() for cross-checking? Both Append and MergeAppend already have a 'apprelids' field that we can save a copy of in the PartitionPruneInfo. Tried that in the attached delta patch. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
PartitionPruneInfo-relids.patch
Description: Binary data
