Обсуждение: Calling ROUND w/o a numeric cast blowing up all connections (9.1)

Поиск
Список
Период
Сортировка

Calling ROUND w/o a numeric cast blowing up all connections (9.1)

От
Wells Oliver
Дата:
I don't know why this is happening, but it's infuriating. From the psql
prompt:

mydb=# select round(5/2, 1);
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Failed.

This kills any connection to the database. Doing 'round(5/2::numeric, 1)'
works fine.

Version: PostgreSQL 9.1.7 on x86_64-unknown-linux-gnu, compiled by
gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3, 64-bit

Nothing shows up in the log.

Have I broken my cast function? My round function? Have I angered the RDMS
gods? Can anyone give me any pointers?

--
Wells Oliver
wellsoliver@gmail.com

Re: Calling ROUND w/o a numeric cast blowing up all connections (9.1)

От
Tom Lane
Дата:
Wells Oliver <wellsoliver@gmail.com> writes:
> I don't know why this is happening, but it's infuriating. From the psql
> prompt:

> mydb=# select round(5/2, 1);
> SSL SYSCALL error: EOF detected

Huh.  Works for me ...

> Nothing shows up in the log.

Either your logging is broken or you're looking in the wrong log, I
think, because that sure looks like a backend crash.  And the postmaster
would certainly bleat about a backend crash.

> Have I broken my cast function? My round function? Have I angered the RDMS
> gods? Can anyone give me any pointers?

Dunno, have you messed around with either casting or round()?  Can you
reproduce this in a freshly-created database?

FWIW, a stock database ought to have these versions of round():

postgres=# \df round
                          List of functions
   Schema   | Name  | Result data type | Argument data types |  Type
------------+-------+------------------+---------------------+--------
 pg_catalog | round | double precision | double precision    | normal
 pg_catalog | round | numeric          | numeric             | normal
 pg_catalog | round | numeric          | numeric, integer    | normal
(3 rows)


            regards, tom lane

Re: Calling ROUND w/o a numeric cast blowing up all connections (9.1)

От
Wells Oliver
Дата:
Ah, bananas. Someone had created a round(double, integer) function in
public that did some shenanigans. Now I've wasted everyone's time.

Though, I do find it odd that it could cause such a crash, bad function or
no.


On Fri, Feb 8, 2013 at 5:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Wells Oliver <wellsoliver@gmail.com> writes:
> > I don't know why this is happening, but it's infuriating. From the psql
> > prompt:
>
> > mydb=# select round(5/2, 1);
> > SSL SYSCALL error: EOF detected
>
> Huh.  Works for me ...
>
> > Nothing shows up in the log.
>
> Either your logging is broken or you're looking in the wrong log, I
> think, because that sure looks like a backend crash.  And the postmaster
> would certainly bleat about a backend crash.
>
> > Have I broken my cast function? My round function? Have I angered the
> RDMS
> > gods? Can anyone give me any pointers?
>
> Dunno, have you messed around with either casting or round()?  Can you
> reproduce this in a freshly-created database?
>
> FWIW, a stock database ought to have these versions of round():
>
> postgres=# \df round
>                           List of functions
>    Schema   | Name  | Result data type | Argument data types |  Type
> ------------+-------+------------------+---------------------+--------
>  pg_catalog | round | double precision | double precision    | normal
>  pg_catalog | round | numeric          | numeric             | normal
>  pg_catalog | round | numeric          | numeric, integer    | normal
> (3 rows)
>
>
>                         regards, tom lane
>



--
Wells Oliver
wellsoliver@gmail.com

Re: Calling ROUND w/o a numeric cast blowing up all connections (9.1)

От
Tom Lane
Дата:
Wells Oliver <wellsoliver@gmail.com> writes:
> Ah, bananas. Someone had created a round(double, integer) function in
> public that did some shenanigans. Now I've wasted everyone's time.

> Though, I do find it odd that it could cause such a crash, bad function or
> no.

Well, if it was a misdeclared alias for a C function, it's not
surprising at all.  If it was something else, it'd be interesting to see
what.

            regards, tom lane