On Mon, Oct 23, 2023 at 11:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> However ... the need to fetch that data is ultimately coming from
> index_unchanged_by_update, and I don't see how that is not buggy
> as can be, independently of this. How can it be okay to ignore
> the effects of BEFORE triggers when deciding if an index is unchanged?
> If this is because it's "only a hint" and doesn't have to be reliable,
> okay, but the documentation around indexUnchanged utterly fails to
> make that clear. I fear some poor index AM writer is going to get
> screwed big time when they assume this flag is good for more than
> heuristic decisions about when to do noncritical maintenance.
That's fair, though note that index_unchanged_by_update does at least
own the fact that it ignores the effects of BEFORE triggers in code
comments. It also doesn't care about predicates in partial indexes,
for reasons that are fairly specific to the way that the hint is
actually used on the nbtree side.
> The reason I'm on about that is that if it's okay for
> index_unchanged_by_update to lie, another approach we could consider
> is to return a default result if we're looking at a child table
> for which we lack updatedCols data. We might have to do that in
> v16, since we don't have much wiggle room to adjust the
> RTEPermissionInfo data in a released branch.
Note that index_unchanged_by_update already lies on v14: it
unconditionally indicates that any non-HOT update has unchanged
indexes for all indexes, regardless of their individual status. This
was due to a pragmatic trade-off made when looking for a backpatchable
fix, but I don't think that there's actually much downside to it. In
general I suspect that index_unchanged_by_update is a little
overengineered.
--
Peter Geoghegan