Re: [PATCH] Fix null pointer dereference in PG19

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-04-21 23:12:45
Message-ID: CA+renyVUCNzfbjzTKvDnnMvVUqiAsVJDaaZmCXhGksWTW8gnNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Aleksander Alekseev <aleksander(at)tigerdata(dot)com> writes:
> > I propose fixing this by explicitly forbidding using the named
> > features together. See the patch.
>
> Checking this at parse time is completely the wrong thing.
> The view could have gained (or lost) triggers by the time
> it's executed.
>
> Actually, looking at it, transformForPortionOfClause is quite
> full of premature error checks:
>
> * I'd tend to move the anti-FDW check to execution too.
> It's not actively wrong, since nowadays we don't permit
> relations to change relkind, but it seems out of place.
> Also, it seems inadequate to deal with the case of a target
> that is a partitioned table having FDW partitions.
>
> * contain_volatile_functions_after_planning is utterly wrong
> to apply here. That should happen somewhere in the planner,
> where it'd be cheaper as well as not premature.
>
> * I'm inclined to think that pretty much all the mucking with
> opclasses is misplaced too: those structures are not immutable
> either. All of that should move to rewriting, planning, or
> even executor startup.

Thanks for this feedback! I will work on a patch to move those checks
to different phases, and also guard against FDW partitions.

Yours,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-04-21 23:28:40 Re: [PATCH] Fix null pointer dereference in PG19
Previous Message Chao Li 2026-04-21 22:24:04 Re: bufmgr: pass through I/O stats context in FlushUnlockedBuffer()