| 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: | Whole Thread | Raw Message | 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
| 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 |