Re: Caching a partition index's parent OID in the relcache?

On 2026-Jul-17, Ayush Tiwari wrote:

> -- 3-level r > m > l; warm l's index cache
> INSERT INTO r VALUES (1) ON CONFLICT (i) DO NOTHING;
> NOTICE: FILL l_pkey ancestors=[m_pkey r_pkey]
> ALTER TABLE r DETACH PARTITION m;
> ALTER TABLE r2 ATTACH PARTITION m ...; -- m_pkey now under r2_pkey
> INSERT INTO r2 VALUES (2) ON CONFLICT (i) DO NOTHING;
> NOTICE: HIT l_pkey cached=[m_pkey r_pkey] live=[m_pkey r2_pkey] <-STALE
>
> l_pkey is never invalidated, so the cached list keeps r_pkey and
> ExecInitPartitionInfo() would pick the wrong arbiter. The
> immediate-parent cache dodges this: it stores only the leaf's own parent
> (invalidated when it changes) and walks the rest live.

I see.

> To make a full list safe we'd need a new invalidation path that, on any
> index re-parent, invalidates the whole descendant-index subtree rather
> than just the re-parented index, and it only helps 3+ level
> hierarchies. Should I explore that?

I think we should do that. Reparenting an index is a very uncommon
operation, so it doesn't matter if it emits several invalidation
messages. On the other hand, if we limit the caching to just the
immediate index, then we have good performance for the easy case of a
single partitioning level, but everyone using more than that will have
to pay a performance cost (on every INSERT ON CONFLICT) that's not
easily visible.

Thanks!

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/