pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, Richard Guo <guofenglinux@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>
Subject: Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
Date: Fri, 12 Jan 2024 12:28:26 -0500
Message-ID: <492826.1705080506@sss.pgh.pa.us> (raw)
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>

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





view thread (37+ messages)  latest in thread

Message-ID: <492826.1705080506@sss.pgh.pa.us>
Permalink:  ../492826.1705080506@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/492826.1705080506@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, robertmhaas@gmail.com, guofenglinux@gmail.com, andres@anarazel.de, pg@bowt.ie
  Subject: Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
  In-Reply-To: <492826.1705080506@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox