Feedback-ID: ie0a040ee:Fastmail
Message-ID: <82f35e5c-9983-4c97-8567-451bc2cb8761@eisentraut.org>
Date: Thu, 9 Jul 2026 10:32:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Fix null pointer dereference in PG19
To: Paul A Jungwirth <pj@illuminatedcomputing.com>,
 Tom Lane <tgl@sss.pgh.pa.us>
Cc: Aleksander Alekseev <aleksander@tigerdata.com>,
 PostgreSQL Development <pgsql-hackers@postgresql.org>
References: 
 <CAJ7c6TME+ix6VRf-2TPnVTsj8qn_hy6sYAOmMhZEivwsu2wS6g@mail.gmail.com>
 <626986.1776785090@sss.pgh.pa.us>
 <CACJufxFgKVL=NnPocAwhRFqpLHckN3N1Ndf7FjGNTdtsAA26mg@mail.gmail.com>
 <CA+renyW52FJ=+pnh+N_xqjUev_MNUCk_mgD2UC7UT0jyAHCE8Q@mail.gmail.com>
 <84f20d0d-3bc8-4843-bd7e-21bce20f8582@eisentraut.org>
 <CAJ7c6TO+kTwk5MBayLARxsPk-YCsDt2QH9P_PeTYoc3zPYCS3Q@mail.gmail.com>
 <CA+renyU6UZnpkgAuog0BVhqyD=G+_UVLzN2Ccpt2sV-qkF-_VQ@mail.gmail.com>
 <CAJ7c6TN7dekEHU8Vu4jV5+Zq7h2cVZQgwkYFCrU0jrjT26-ANw@mail.gmail.com>
 <CA+renyXs5mkPb-Vg=uF2Hj0jP2ufutc1_Eht=eb3+b_WpjiqLg@mail.gmail.com>
 <4984118e-0dc5-49a9-b279-fd0b707be8e0@eisentraut.org>
 <CA+renyUkKaWtWZX2UcojKVjM=f1F5kgdvR8Pr5QqyJqqe_dw-g@mail.gmail.com>
 <391a2845-105b-4048-a113-835c2742fea1@eisentraut.org>
 <CA+renyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg@mail.gmail.com>
 <1894792.1783476457@sss.pgh.pa.us>
 <CA+renyV1WUtDSOHpNVv3fhD6JqhzZY_mV-0Nks23MczXLxpE8A@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: 
 <CA+renyV1WUtDSOHpNVv3fhD6JqhzZY_mV-0Nks23MczXLxpE8A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/82f35e5c-9983-4c97-8567-451bc2cb8761%40eisentraut.org>
Precedence: bulk

On 08.07.26 18:48, Paul A Jungwirth wrote:
> 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

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?