Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)
Date
Msg-id CAEudQAr4Eevx6BO-xmyAVoxGsVyCoqENPqc1Hg_LguxPMdKwtw@mail.gmail.com
Whole thread Raw
In response to Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Em ter., 17 de jun. de 2025 às 11:10, Aleksander Alekseev <aleksander@timescale.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Non-reproducible AIO failure
Next
From: Andres Freund
Date:
Subject: Re: Add progressive backoff to XactLockTableWait functions