Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)
Date: 2025-06-17 14:59:31
Message-ID: 158F1477-700B-4C05-954B-78FE5A4BA759@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 17 Jun 2025, at 15:43, Tomas Vondra <tomas(at)vondra(dot)me> wrote:

> .. if we
> get a failure here, it's not clear to me we can really keep the system
> running anyway. It's not just the usual "relcache miss" and if the user
> retries it will probably work fine. The catalog is borked, and who knows
> in what way.

Agreed.

> My opinion is that adding a "elog(ERROR)" here would be misleading, as
> it implies it's something we expect. And mostly pointless. I can imagine
> adding an Assert, but I don't quite see how is that better than just
> hitting a segfault a couple lines later.

If I break something here while hacking I'd probably prefer a segfault to an
Assert.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2025-06-17 15:08:11 Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Previous Message Konstantin Knizhnik 2025-06-17 14:54:12 Re: Non-reproducible AIO failure