Horton

Re: Inval reliability, especially for inplace updates

Paul A Jungwirth <pj@illuminatedcomputing.com>

View thread
From: Paul A Jungwirth <pj@illuminatedcomputing.com>
To: Noah Misch <noah@leadboat.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Nitin Motiani <nitinmotiani@google.com>, Andres Freund <andres@anarazel.de>, Ilyasov Ian <ianilyasov@outlook.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Surya Poondla <s_poondla@apple.com>
Date: 2025-12-12T17:48:48Z
Lists: pgsql-hackers 
On Thu, Dec 11, 2025 at 4:24 PM Noah Misch <noah@leadboat.com> wrote:
>
> On Thu, Dec 04, 2025 at 04:19:02PM -0800, Noah Misch wrote:
> > Thanks for the review.
>
> > The attached version doesn't need a comprehensive re-review, but I'd
> > particularly value hearing about any places where you find it's reducing
> > comprehensibility rather than enhancing.
>
> I'd like to get this into the back branches well in advance of the 2026-02
> releases, in case the buildfarm catches some defect at low probability.  If
> there are no objections in the next week, I'll proceed that way.

I'm happy with these new comments. The explanation in
heap_inplace_lock before calling CacheInvalidateHeapTupleInplace is a
lot better I think. And removing the last param means there is less to
think about.

Thanks!

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com