Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
Date
Msg-id CA+TgmoYcYwBxV7J_Us=zz7Wchbg1+M6jPdbogZFYZD1WmZB9ZQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
On Fri, Jan 12, 2024 at 8:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> I had decided to move that step out of "if (epqslot_candidate != NULL)"
> in v3 to play safe when removing ExecMaterializeSlot(newslot) brought by
> 75e03eabe (more details upthread [1]). I thought that if that commit stated
> that the slot needs materialization (it was time before 86dc90056, which
> raised the current issue), then the materialization must be preserved.
> (The same commit can be found in zheap repository [2], but I found no other
> explanation of it's purpose...)
> Though looking at the current core code, I'm inclined to perform
> ExecMaterializeSlot() only when we have epqslot_candidate, if we can afford
> not to bother about that zheap-specific or similar scenario...

I don't understand why it's ever safe to skip ExecMaterializeSlot
here. IIUC, if we have no EPQ slot, newslot is still not materialized
and thus dependent on oldslot ... and we're about to
ExecFetchSlotHeapTuple on oldslot.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18287: pg_restore with -C and -c options does not do what is said in the documentation
Next
From: Tom Lane
Date:
Subject: Re: BUG #18284: Filter in left lateral join not respected