From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Richard Guo <guofenglinux(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |
Date: | 2024-01-12 20:26:22 |
Message-ID: | CA+Tgmoa+1HXZAOYiHL5_=+akjyRSDLcHBx-FvmfuwsvFXCkAKg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Jan 12, 2024 at 12:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After sleeping on it, I'm inclined to the opinion that unconditionally
> materializing newslot here is a good idea.
I'm glad you came to that conclusion, and I agree. I think it's really
bad that we're passing around un-materialized slots across many layers
of the call stack; having the behavior of the inner code know in
detail which outer code paths materialize the slot and which don't
seems like a recipe for infinite future bugs. The only concern is
overhead, IMV.
> 75e03eabe
> should be sufficient evidence that there's a lot of hazard here
> (and I especially like being able to revert that wart).
I haven't analyzed whether this allow reverting that, but it seems
nice if it does.
Do you want to take this forward from here?
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-01-12 20:52:47 | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |
Previous Message | PG Bug reporting form | 2024-01-12 17:57:55 | BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global |