Re: [PATCH] Fix null pointer dereference in PG19 - Mailing list pgsql-hackers

From Paul A Jungwirth
Subject Re: [PATCH] Fix null pointer dereference in PG19
Date
Msg-id CA+renyVenLk+u=yGvDAyeFEuvkmeQx448-KnnGczqQHB10_fbg@mail.gmail.com
Whole thread
In response to [PATCH] Fix null pointer dereference in PG19  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: [PATCH] Fix null pointer dereference in PG19
List pgsql-hackers
On Tue, Apr 21, 2026 at 4:11 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
>
> On Tue, Apr 21, 2026 at 6:41 AM Aleksander Alekseev
> <aleksander@tigerdata.com> wrote:
> >
> > I discovered that it's possible to crash Postgres when using VIEWS,
> > FOR PORTION OF syntax and INSTEAD OF triggers together. See crash.sql.
> >
> > This happens because in ExecModifyTable() around line 4827 there is no
> > check for `relkind == RELKIND_VIEW`. If this is the case `tupleid`
> > ends up being NULL which causes null pointer dereference later when
> > ExecDeleteEpilogue() or ExecUpdateEpilogue() calls
> > ExecForPortionOfLeftovers() with tupleid = NULL. An example stacktrace
> > is attached.
>
> Thanks for testing FOR PORTION OF! This specific bug has been reported
> already and has a patch at [1].
>
> [1]
https://www.postgresql.org/message-id/CAHg%2BQDd74fnd4obCRMqVS0AVWf%3DcSFH%3DCv7trTJWgm%2B_bhTK6w%40mail.gmail.com
>
> > I propose fixing this by explicitly forbidding using the named
> > features together. See the patch.
>
> I don't think disabling these features is necessary. You are right
> that we can't use the tupleid when we have a view, but I think an
> INSTEAD OF trigger should cause us to skip inserting temporal
> leftovers. (If we didn't do the update, we can't draw conclusions
> about what history was touched vs untouched.)

(Quoting my full message yesterday since I forgot to Reply-All.)

Here is v4 of the fix for this. I'd like to continue the conversation
here since that other thread is huge and attached to the original
commitfest entry for the feature. I'll make a new CF entry for just
this thread.

This patch squashes jian he's test enhancements from his v3 patch.
Also I changed '[2024-01-01,2024-12-31)' to '[2024-01-01,2025-01-01)',
which look less like a mistake (not that it matters to the test), and
I cleaned up the test comment a little.

Yours,

--
Paul              ~{:-)
pj@illuminatedcomputing.com

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Next
From: Paul A Jungwirth
Date:
Subject: Re: SQL:2011 Application Time Update & Delete