public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Paul A Jungwirth <[email protected]>
To: Tom Lane <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: PostgreSQL Development <[email protected]>
Subject: Re: [PATCH] Fix null pointer dereference in PG19
Date: Thu, 9 Jul 2026 10:32:08 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+renyV1WUtDSOHpNVv3fhD6JqhzZY_mV-0Nks23MczXLxpE8A@mail.gmail.com>
References: <CAJ7c6TME+ix6VRf-2TPnVTsj8qn_hy6sYAOmMhZEivwsu2wS6g@mail.gmail.com>
<[email protected]>
<CACJufxFgKVL=NnPocAwhRFqpLHckN3N1Ndf7FjGNTdtsAA26mg@mail.gmail.com>
<CA+renyW52FJ=+pnh+N_xqjUev_MNUCk_mgD2UC7UT0jyAHCE8Q@mail.gmail.com>
<[email protected]>
<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>
<[email protected]>
<CA+renyUkKaWtWZX2UcojKVjM=f1F5kgdvR8Pr5QqyJqqe_dw-g@mail.gmail.com>
<[email protected]>
<CA+renyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg@mail.gmail.com>
<[email protected]>
<CA+renyV1WUtDSOHpNVv3fhD6JqhzZY_mV-0Nks23MczXLxpE8A@mail.gmail.com>
On 08.07.26 18:48, Paul A Jungwirth wrote:
> On Tue, Jul 7, 2026 at 7:07 PM Tom Lane <[email protected]> wrote:
>>
>> Paul A Jungwirth <[email protected]> writes:
>>> On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <[email protected]> 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?
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Fix null pointer dereference in PG19
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox