Re: [PATCH] Fix null pointer dereference in PG19

Paul A Jungwirth <pj@illuminatedcomputing.com>

From: Paul A Jungwirth <pj@illuminatedcomputing.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>, Aleksander Alekseev <aleksander@tigerdata.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2026-07-08T16:48:08Z
Lists: pgsql-hackers

Attachments

On Tue, Jul 7, 2026 at 7:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> > On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Checking this at parse time is completely the wrong thing.
> >> The view could have gained (or lost) triggers by the time
> >> it's executed.
>
> > But INSTEAD OF triggers are selected in the rewriter, which uses the
> > same relcache snapshot as parse analysis. And a concurrent change
> > can't sneak in different triggers, because that causes a relcache
> > invalidation, so we redo the parse & rewrite phases.
>
> You have forgotten about views and rewrite rules.  Those go to disk in
> post-parser form, and will be rewritten only at execution sometime
> later, *without* a re-parse.

Ah yes, thank you! I should have been able to work that out.

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

These are against REL_19_STABLE, not master (but I don't think it
makes a difference).

Yours,

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