Re: [PATCH] Fix null pointer dereference in PG19

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-08 02:07:37
Message-ID: 1894792.1783476457@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> writes:
> On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-07-08 02:17:06 Re: Reject ill-formed range bounds histograms in pg_restore_attribute_stats()
Previous Message Paul A Jungwirth 2026-07-08 01:45:46 Re: [PATCH] Fix null pointer dereference in PG19