Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: dan-eli(at)mail(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later
Date: 2025-01-28 20:04:35
Message-ID: 1414969.1738094675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2025-01-28 13:58:13 +0000, PG Bug reporting form wrote:
>> Hello, I suggest the following patch for this issue.
>>
>> @@ -905,6 +905,8 @@ ExtendBufferedRelTo(BufferManagerRelation bmr,
>> bmr.smgr->smgr_cached_nblocks[fork] == InvalidBlockNumber)
>> &&
>> !smgrexists(bmr.smgr, fork))
>> {
>> +
>> + Assert(bmr.rel != NULL);
>> LockRelationForExtension(bmr.rel, ExclusiveLock);

> I guess it couldn't hurt to add them. It's fine for existing callers...

Seems quite pointless really. If bmr.rel is NULL, the
LockRelationForExtension call will SIGSEGV all by itself.
Transforming that into a SIGABRT isn't moving the football much.

The actually interesting question is whether it's possible to
reach there with bmr.rel being NULL, and if so what we have to do
to avoid such a crash. Adding an Assert still doesn't help.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2025-01-28 20:12:17 Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later
Previous Message Andres Freund 2025-01-28 19:55:38 Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later