Re: dsm_unpin_segment - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: dsm_unpin_segment
Date
Msg-id CAA4eK1JipuFUiGOmHMmcXtFcSqC7mjQ0WjV0F1W=OGoCsLJ5DQ@mail.gmail.com
Whole thread Raw
In response to Re: dsm_unpin_segment  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, Aug 20, 2016 at 6:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Aug 20, 2016 at 7:37 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> 2.
>> + if (dsm_control->item[seg->control_slot].pinned)
>> + elog(ERROR, "cannot pin a segment that is already pinned");
>>
>> Shouldn't this be a user facing error (which means we should use ereport)?
>
> Uh, certainly not.  This can't happen because of SQL the user enters;
> it can only happen because of a C coding error.  elog() is the
> appropriate tool for that case.
>

Okay, your point makes sense to me, but in that case why not use an
Assert here?  I think elog() could also be used here as well, but it
seems to me elog() is most appropriate for the cases where it is not
straightforward to tell the behaviour of API or value of variable like
when PageAddItem() is not successful.

voiddsm_pin_segment(dsm_segment *seg)

+void
+dsm_unpin_segment(dsm_handle handle)

Another point, I want to highlight here is that pin/unpin API's have
different type of arguments.  The comments on top of function
dsm_unpin_segment() explains the need of using dsm_handle which seems
reasonable.  I just pointed out to see if anybody else has a different
view.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location
Next
From: Emre Hasegeli
Date:
Subject: Re: SP-GiST support for inet datatypes