On Wed, 2025-10-08 at 15:48 -0500, Nathan Bossart wrote:
> > The theory being that
> > my new code using the old/new tts to form and test the index tuples
> > resulting from executing expressions was using the resultsRelInfo
> > struct
> > created during plan execution, not the information found on the
> > page,
> > and so was safe without the lock.
>
> An open question (at least from me) is whether this is safe. I'm not
> familiar enough with this area of code yet to confidently determine
> that.
The optimization requires that the expression evaluates to the same
thing on the old and new tuples. That determination doesn't have
anything to do with a lock on the buffer, so long as the old tuple
isn't pruned away or something. And clearly it won't be pruned, because
we're in the process of updating it, so we have a snapshot that can see
it.
There might be subtleties in other parts of the proposal, but the above
determination can be made safely without a buffer lock.
>
> > I added a reloption "expression_checks" to disable this new code
> > path.
> > Good idea or bad precedent?
>
> If there are cases where the added overhead outweighs the benefits
> (which
> seems like it must be true some of the time), then I think we must
> have a
> way to opt-out (or maybe even opt-in). In fact, I'd advise adding a
> GUC to
> complement the reloption so that users can configure it at higher
> levels.
I'll push back against this. For now I'm fine with developer options to
make testing easier, but we should find a way to make this work well
without tuning.
Regards,
Jeff Davis
