| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| 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> |
| Subject: | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |
| Date: | 2023-04-30 22:00:40 |
| Message-ID: | 20230430220040.ts63t23qzgxqatxf@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2023-04-29 18:24:47 -0400, Tom Lane wrote:
> A completely different way of looking at it is that we should not
> treat this as ExecBRUpdateTriggers's bug at all. The slot mechanisms
> are supposed to protect the data referenced by a slot, so why is that
> failing to happen in this example? The correct fix might involve
> newslot acquiring a buffer pin, for example.
I think the slot mechanism today (and historically) doesn't protect against
quite a few such scenarios - and it's not clear how to change that. Most of
the scenarios where we need to materialize are because the underlying memory
is going to be released / reset, i.e. we don't hold a buffer pin in the first
place. I guess we could try to protect against that by registering a memory
context hook, but that'd be a very heavyweight mechanism.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-04-30 22:09:50 | Re: BUG #17909: CREATE SCHEMA AUTHORIZATION sch CREATE TABLE foo ( id INT ) will coredump |
| Previous Message | Peter Geoghegan | 2023-04-30 20:39:37 | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |