From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pg15.3: dereference null *plan in CachedPlanIsSimplyValid/plpgsql
In-reply-to: <ZLlV+STFz1l/WhAQ@telsasoft.com>
References: <ZLlV+STFz1l/WhAQ@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Thu, 20 Jul 2023 10:42:49 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <584103.1689868532.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Jul 2023 11:55:32 -0400
Message-ID: <584104.1689868532@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/584104.1689868532%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> A production instance crashed like so.

Oh, interesting.  Apparently we got past the "Has cache invalidation fired
on this plan?" check:

    if (!plansource->is_valid || plan !=3D plansource->gplan || !plan->is_=
valid)
        return false;

because "plan" and "plansource->gplan" were *both* null, which is
a case the code wasn't expecting.  plansource.c seems to be paranoid
about gplan possibly being null everywhere else but here :-(

> Note that the prior query seems to have timed out in the same / similar =
plpgsql
> statement:

Hm.  Perhaps that helps explain how we got into this state.  It must
be some weird race condition, given the lack of prior reports.
Anyway, adding a check for plan not being null seems like the
obvious fix.

			regards, tom lane