Re: pointless check in RelationBuildPartitionDesc

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pointless check in RelationBuildPartitionDesc
Date: 2018-09-05 00:45:45
Message-ID: ccb88e11-8e4b-9781-6807-20c38181482f@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018/09/04 21:51, Alvaro Herrera wrote:
> On 2018-Sep-04, Amit Langote wrote:
>
>> On 2018/09/04 13:08, Alvaro Herrera wrote:
>
>>> I think it'd be pointless noise. If we really want to protect against
>>> that, I think we should promote the Assert for relpartbound's isnull
>>> flag into an if test.
>>
>> So that we can elog(ERROR, ...) if isnull is true? If so, I agree,
>> because that's what should've been done here anyway (for a value read from
>> the disk that is).
>
> Yes.
>
> I wonder now what's the value of using an Assert for this, BTW: if those
> are enabled, then we'll crash saying "this column is null and shouldn't!".
> If they are disabled, we'll instead crash (possibly in production)
> trying to decode the field. What was achieved?

I can see how that the Assert was pointless all along.

> With an elog(ERROR) the reaction is the expected one: the current
> transaction is aborted, but the server continues to run.
>
>> I think we should check relispartition then too.
>
> Well, we don't check every single catalog flag in every possible code
> path just to ensure it's sane. I don't see any reason to do differently
> here. We rely heavily on the catalog contents to be correct, and
> install defenses against user-induced corruption that would cause us to
> crash; but going much further than that would be excessive IMO.

Okay, sure anyway.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2018-09-05 00:47:52 Re: Bug fix for glibc broke freebsd build in REL_11_STABLE
Previous Message Michael Paquier 2018-09-04 23:34:36 Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace