Re: Inval reliability, especially for inplace updates

On Fri, Nov 01, 2024 at 04:38:29PM -0700, Noah Misch wrote:
> This was a near miss to having a worst-in-years regression in a minor release,
> so I'm proposing this sequence:
>
> - Revert from non-master branches commits 8e7e672 (inplace180, "WAL-log
> inplace update before revealing it to other sessions.") and 243e9b4
> (inplace160, "For inplace update, send nontransactional invalidations.").
>
> - Back-patch inplace230-index_update_stats-io-before-buflock to harden commit
> a07e03f (inplace110, "Fix data loss at inplace update after heap_update()").
>
> - Push attached inplace240 to master.
>
> - Make the commitfest entry a request for review of v17 inplace160+inplace240.
> After some amount of additional review and master bake time, the reverted
> patches would return to non-master branches.
>
> If someone agrees or if nobody objects by 2024-11-02T15:00+0000, I'll make it
> so. That's not much time, but I want to minimize buildfarm members hanging
> and maximize inplace230 bake time before the release wrap.

Pushed as 0bada39.

Buildfarm member hornet REL_15_STABLE was in the same hang. Other buildfarm
runs 2024-10-25T13:51:02Z - 2024-11-02T16:04:56Z may hang the same way. It's
early to make a comprehensive list of hung buildfarm members, since many
reported infrequently even before this period. I'll wait a week or two and
then contact the likely-hung member owners. I regret the damage.

To make explicit something I didn't call out above, v12-v17 commit a4668c9 "At
end of recovery, reset all sinval-managed caches." is still in the tree.
That's despite it originating to serve the now-reverted back branch versions
of 243e9b4. It could prevent post-recovery corruption, and its risks are
orthogonal to the risks of the reverted code.

I'm attaching the v17 patch that now becomes the commitfest submission
associated with this thread.