Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
От | Robert Haas |
---|---|
Тема | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |
Дата | |
Msg-id | CA+TgmoYcYwBxV7J_Us=zz7Wchbg1+M6jPdbogZFYZD1WmZB9ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
|
Список | 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 по дате отправления: