Re: [PATCH] Fix null pointer dereference in PG19

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: [PATCH] Fix null pointer dereference in PG19
Date: 2026-06-29 07:38:34
Message-ID: CA+renyXs5mkPb-Vg=uF2Hj0jP2ufutc1_Eht=eb3+b_WpjiqLg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 25, 2026 at 3:32 AM Aleksander Alekseev
<aleksander(at)tigerdata(dot)com> wrote:
>
> This patch rotted and needed a rebase (attached as .txt).

Thank you for taking care of the rebase!

> Also it's
> incorrect, it only masks the crash:
>
> ```
> CREATE TABLE t (id int, valid_at daterange, val int);
> INSERT INTO t VALUES (1, '[2024-01-01,2025-01-01)', 100);
> CREATE VIEW v AS SELECT * FROM t;
>
> CREATE FUNCTION trig_fn() RETURNS trigger LANGUAGE plpgsql AS $$
> BEGIN
> RAISE NOTICE 'UPDATE OLD: %, NEW: %', OLD, NEW;
> RETURN NEW;
> END;
> $$;
>
> CREATE TRIGGER trig INSTEAD OF UPDATE ON v FOR EACH ROW EXECUTE
> FUNCTION trig_fn();
> UPDATE v FOR PORTION OF valid_at FROM '2024-04-01' TO '2024-08-01' SET
> val = 999 WHERE id = 1;
>
> server closed the connection unexpectedly
> ```

You're right, this was due to a copy/paste bug (looking for a delete
trigger in the update code). By splitting the test into two triggers,
we catch the problem and correctly skip the leftovers. I've attached a
patch with that correction.

> IMO it's a little bit late in the PG19 cycle for making this work.
> This is an implementation of a new feature which is not present at the
> moment which to my knowledge we don't do after the feature freeze. Our
> goal is to fix the crash and leave the rest for the PG20 cycle.
> Clearly the feature needs more discussion and thorough testing.

I don't really think this is a new feature. It is a fix to make FOR
PORTION OF not execute when it shouldn't. The change here is quite
simple.

But I don't mind holding it back if that's what people want to do.
Looking more closely at INSTEAD OF triggers, I found another bug: the
FOR PORTION OF qual (and TLE) were not added, so the trigger would
fire on more rows than it should, and NEW.valid_at was not
pre-computed. The second patch here fixes that. I'll defer to others
whether we should fix the INSTEAD OF interaction now or wait 'til v20.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

Attachment Content-Type Size
v6-0001-Skip-FOR-PORTION-OF-leftovers-after-INSTEAD-OF-tr.patch text/x-patch 7.7 KB
v6-0002-Fix-INSTEAD-OF-targeting-too-many-rows-with-FOR-P.patch text/x-patch 7.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-06-29 07:42:49 Re: Adding basic NUMA awareness
Previous Message Chao Li 2026-06-29 07:20:24 Fix GROUP BY ALL handling of ORDER BY operator semantics