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
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 |