Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later
От | Tom Lane |
---|---|
Тема | Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later |
Дата | |
Msg-id | 1414969.1738094675@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.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
В списке pgsql-bugs по дате отправления: