Re: Numeric multiplication overflow errors

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Numeric multiplication overflow errors
Date: 2021-07-05 12:01:35
Message-ID: CAApHDvq3mBd1QVvv8O56wOvG4friH-a7U-pouDpg3CRjeU5Orw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 5 Jul 2021 at 23:07, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>
> Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> escreveu:
>> Note, however, that it won't make any difference to performance in the
>> way that you're suggesting -- elog() in Postgres is used for "should
>> never happen, unless there's a software bug" errors, rather than, say,
>> "might happen for certain invalid inputs" errors, so init_var() should
>> always be called in these functions.
>
> I agree that in this case, most of the time, elog is not called.

You may have misunderstood what Dean meant. elog(ERROR) calls are now
exclusively for "cannot happen" cases. If someone gets one of these
then there's a bug to fix or something else serious has gone wrong
with the hardware.

The case you seem to be talking about would fit better if the code in
question had been ereport(ERROR).

I don't disagree that the initialisation is better to happen after the
elog. I'm just mentioning this as I wanted to make sure you knew the
difference between elog(ERROR) and ereport(ERROR).

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ronan Dunklau 2021-07-05 12:07:05 Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Previous Message Andrew Dunstan 2021-07-05 11:32:08 Re: Excessive cost of OpClassCache flushes in CLOBBER_CACHE_ALWAYS mode