Re: dsm_unpin_segment

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dsm_unpin_segment
Date: 2016-08-21 05:45:36
Message-ID: CAA4eK1JipuFUiGOmHMmcXtFcSqC7mjQ0WjV0F1W=OGoCsLJ5DQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 20, 2016 at 6:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Aug 20, 2016 at 7:37 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.

void
dsm_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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Emre Hasegeli 2016-08-21 08:41:50 Re: SP-GiST support for inet datatypes
Previous Message Amit Kapila 2016-08-21 04:43:57 Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location