Re: [PATCH] Fix null pointer dereference in PG19

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Fix null pointer dereference in PG19
Date: 2026-07-09 15:22:38
Message-ID: CA+renyWb-253nMz4OXPwn5ebXF7oJqT2Wu=qrGv=awYFqOk2LA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 9, 2026 at 1:32 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> > Here is another patch series. No code changes, but I inserted a new
> > patch with tests showing that parse-time checking crashes, but
> > rewrite-time and exec-time checking catches the forbidden statement.
> > So the series is:
> >
> > v1: parse-time check, tests pass
> > v2: add tests that crash the server
> > v3: rewrite-time check: tests pass
> > v4: exec-time check: tests pass
>
> What do you want to do with these? Here you list them as four different
> versions, but the attachments are four incremental patches of the same
> version. Do you propose to apply all of them?
>
> It seems we definitely do want the exec-time check. And I can see maybe
> the parse-time check as an additional user-friendliness feature. But
> maybe we don't need to check three times?

I should have called them part{1-4} instead of v{1-4}. My intent is to
squash them, but I thought separating the changes clarified the
problem and how v3/v4 fix it. Either squash v1-3 if you want to check
at rewrite time, or v1-4 if you want to check at exec time.

Each part removes the check from the prior part, so there is only one
check, it's just a question of when we do it.

Checking at v1 is Aleksander's original patch. Then v2 adds tests that
crash the server. v3 moves the check to rewrite time, and the tests
pass. v4 moves the check again to exec time. But v4 is a behavior
change: an UPDATE that touches zero rows no longer fails. I thought
that was weird; that's why I recommended leaving it out (in
https://www.postgresql.org/message-id/CA%2BrenyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg%40mail.gmail.com
before I added the crashing tests).

I like your idea of keeping the parse-time check too. Then we can show
line numbers. Want a patch with that?

If we check at both rewrite-time and exec-time, the exec-time check
will never happen (as far as I can tell). If we want something there,
maybe it should be an Assert or an elog.

I can give you one squashed file if you like. After reading your
email, my preference is to check at parse time, check again at rewrite
time, and Assert at exec time.

Yours,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2026-07-09 15:24:59 Re: Hash index bucket split bug
Previous Message Tom Lane 2026-07-09 15:22:12 Re: json/jsonb cleanup + FmgrInfo caching