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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)
Date: 2025-06-17 14:16:51
Message-ID: CAEudQAr4Eevx6BO-xmyAVoxGsVyCoqENPqc1Hg_LguxPMdKwtw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 17 de jun. de 2025 às 11:10, Aleksander Alekseev <
aleksander(at)timescale(dot)com> escreveu:

> Hi Ranier,
>
> > To me this is a contradiction, whether you consider waiting for a
> segfault or consider adding an Assert.
> > For the user it is better to have a log, where he can quickly find the
> problem, rather than having to investigate on his own.
>
> That's the point. User's shouldn't encounter this.

It shouldn't.

> Thus there is no
> reason to break branch prediction for everyone here.
>
For now there is no consensus that there will not be a segfault.
If a segfault will never occur, ok.
IMO, this is not a query-dependent issue.
But the table in question is never corrupted or invalid.

best regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-06-17 14:17:27 Re: Add progressive backoff to XactLockTableWait functions
Previous Message Tom Lane 2025-06-17 14:15:37 Re: Non-reproducible AIO failure