From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org,
        Richard Guo <guofenglinux@gmail.com>,
        Andres Freund <andres@anarazel.de>, Peter Geoghegan <pg@bowt.ie>
Subject: Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW
 UPDATE trigger
In-reply-to: <17124cd9-6515-2076-6eac-40d44388f833@gmail.com>
References: <17798-0907404928dcf0dd@postgresql.org>
 <87fe6c28-80b2-f709-a8db-d105e5240e39@gmail.com>
 <CAMbWs4_pg7ab=OJF2CGLzs=noWEjujerxfo92sm3RL9ce=ogsQ@mail.gmail.com>
 <CAMbWs48FHhuuuWbxygO4Wey7ahdaSwRjzJODKXx7=GFsge_aLg@mail.gmail.com>
 <f5ff446f-72e2-44f7-80c6-4256cf7caeb3@gmail.com>
 <a4a8cf37-e9d5-3c58-fc2e-d217cf66f315@gmail.com>
 <1849610.1682807087@sss.pgh.pa.us>
 <e989408c-1838-61cd-c968-1fcf47c6fbba@gmail.com>
 <CA+TgmoZz1fGaTnOSf1yQhwYovEEkJZ9iioQXnLgaJz+1fBip=g@mail.gmail.com>
 <494cd7c4-c109-6886-c0e3-138a95e7e38b@gmail.com>
 <CA+TgmoYAsQWMqMUNNdyp8V0KVxMoz=0y+3XNCf3ST-o1yyz5Jg@mail.gmail.com>
 <74335d44-819d-60e0-859a-efe74d9c84c2@gmail.com>
 <CA+TgmoYkOp=jDg15ugJDwxqoA6drAPBZmOJkhZJ11HZWhEYx6w@mail.gmail.com>
 <b64c183f-4ae1-0b16-afcf-11101ebc4213@gmail.com>
 <CA+TgmobRr7iWYNNj+-djD6AkoS5trpL8JznXbfO74+dtmCsOsg@mail.gmail.com>
 <325298.1705009396@sss.pgh.pa.us>
 <94ca869c-472b-f1cf-3d7c-aa8530f5475d@gmail.com>
 <CA+TgmoYcYwBxV7J_Us=zz7Wchbg1+M6jPdbogZFYZD1WmZB9ZQ@mail.gmai!
 l.com> <17124cd9-6515-2076-6eac-40d44388f833@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Fri, 12 Jan 2024 20:00:01 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <492825.1705080506.1@sss.pgh.pa.us>
Date: Fri, 12 Jan 2024 12:28:26 -0500
Message-ID: <492826.1705080506@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/492826.1705080506%40sss.pgh.pa.us>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> writes:
> 12.01.2024 17:56, Robert Haas wrote:
>> 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.

> To my understanding, when we have no epqslot_candidate, it means that
> newslot came from ExecBRUpdateTriggers's callers and it can't be dependent
> on an internal oldslot's buffer.

After sleeping on it, I'm inclined to the opinion that unconditionally
materializing newslot here is a good idea.  Given that we're about to
call one or more trigger functions, the incremental cost ought to be
pretty negligible.  The reduction in the state space that we have to
reason about seems fairly significant, too.  Remember that a trigger
function could do almost anything.  So I like this not only for
providing a straightforward fix for the current problem, but as a
guard against unrecognized or future bugs in this area.  75e03eabe
should be sufficient evidence that there's a lot of hazard here
(and I especially like being able to revert that wart).

			regards, tom lane