Re: Inval reliability, especially for inplace updates
| От | Noah Misch |
|---|---|
| Тема | Re: Inval reliability, especially for inplace updates |
| Дата | |
| Msg-id | 20251217032357.32.nmisch@google.com обсуждение исходный текст |
| Ответ на | Re: Inval reliability, especially for inplace updates (Paul A Jungwirth <pj@illuminatedcomputing.com>) |
| Ответы |
Re: Inval reliability, especially for inplace updates
|
| Список | pgsql-hackers |
On Fri, Dec 12, 2025 at 09:48:48AM -0800, Paul A Jungwirth wrote: > 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. I pushed the patch bundle to v17-v14. Thanks for the reviews! The https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet&dt=2025-12-17%2001%3A34%3A36 "double free or corruption (!prev)" likely witnessed a defect in how I back-patched this to v14. I am looking into it.
В списке pgsql-hackers по дате отправления: