Обсуждение: current CVS snapshot of pgsql crash ...
This happens, when I want do this:
(4) $ sql
Welcome to the POSTGRESQL interactive sql monitor: Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66]
type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute queryYou are
currentlyconnected to the database: david
david=> create table t (e oid);
CREATE
david=> insert into t values (lo_import('/tmp/1'));
INSERT 19000 1
david=> \d
Database = david+------------------+----------------------------------+----------+| Owner |
Relation | Type |+------------------+----------------------------------+----------+| david |
t | table || david | xinx18986 | index
|+------------------+----------------------------------+----------+
david=> select textout(byteaout(odata)) from xinv18986;
pqReadData() -- backend closed the channel unexpectedly.This probably means the backend terminated abnormallybefore or
whileprocessing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.
And in log is:
Jun 2 22:56:27 chameleon PGSQL: FATAL 1: Memory exhausted in AllocSetAlloc()
================================
File /tmp/1 contains:
djdjd
djdjdjd
djdjdjdjdjdj
ddjdjdjjd
djdjdjjjdjdjdjdjd
djdjdj
This example doesn't have good meaning, but I dont like crash of my
database ...
thanks,
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@orfinet.cz (mime compatible)
> This happens, when I want do this:
> (4) $ sql
> Welcome to the POSTGRESQL interactive sql monitor:
> Please read the file COPYRIGHT for copyright terms of POSTGRESQL
> [PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66]
>
> type \? for help on slash commands
> type \q to quit
> type \g or terminate with semicolon to execute query
> You are currently connected to the database: david
>
> david=> create table t (e oid);
> CREATE
> david=> insert into t values (lo_import('/tmp/1'));
> INSERT 19000 1
> david=> \d
> Database = david
> +------------------+----------------------------------+----------+
> | Owner | Relation | Type |
> +------------------+----------------------------------+----------+
> | david | t | table |
> | david | xinx18986 | index |
> +------------------+----------------------------------+----------+
>
> david=> select textout(byteaout(odata)) from xinv18986;
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> We have lost the connection to the backend, so further processing is impossible. Terminating.
>
>
> And in log is:
> Jun 2 22:56:27 chameleon PGSQL: FATAL 1: Memory exhausted in AllocSetAlloc()
>
> ================================
> File /tmp/1 contains:
> djdjd
> djdjdjd
> djdjdjdjdjdj
> ddjdjdjjd
> djdjdjjjdjdjdjdjd
> djdjdj
>
> This example doesn't have good meaning, but I dont like crash of my
> database ...
Yes, I see your point.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
David Sauer <davids@orfinet.cz> writes:
> david=> select textout(byteaout(odata)) from xinv18986;
> pqReadData() -- backend closed the channel unexpectedly.
I think this is not related to large objects per se --- it's a
typechecking failure. textout is expecting a text datum, and it's
not getting one because that's not what comes out of byteaout.
(The proximate cause of the crash is that textout tries to interpret
the first four bytes of byteaout's output as a varlena length...)
The parser's typechecking machinery is unable to catch this
error because textout is declared to take any parameter type
whatever (its proargtype is 0).
Why don't the type output functions have the correct input types
declared for them in pg_proc???
For that matter, why do we allow user expressions to call the type
input/output functions at all? They're not really usable as SQL
functions AFAICS...
regards, tom lane
> For that matter, why do we allow user expressions to call the type > input/output functions at all? They're not really usable as SQL > functions AFAICS... What probably happened is that those are in the system catalogs, but are assigned a zero for input, rather than a non-valid oid. Does zero mean any type? I guess so. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> David Sauer <davids@orfinet.cz> writes: > > david=> select textout(byteaout(odata)) from xinv18986; > > pqReadData() -- backend closed the channel unexpectedly. > > I think this is not related to large objects per se --- it's a > typechecking failure. textout is expecting a text datum, and it's > not getting one because that's not what comes out of byteaout. > (The proximate cause of the crash is that textout tries to interpret > the first four bytes of byteaout's output as a varlena length...) > > The parser's typechecking machinery is unable to catch this > error because textout is declared to take any parameter type > whatever (its proargtype is 0). > > Why don't the type output functions have the correct input types > declared for them in pg_proc??? > > For that matter, why do we allow user expressions to call the type > input/output functions at all? They're not really usable as SQL > functions AFAICS... Yes, they take C pointers, don't they. You can't return one of those in any SQL function or column name. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > For that matter, why do we allow user expressions to call the type
> > input/output functions at all? They're not really usable as SQL
> > functions AFAICS...
>
> Yes, they take C pointers, don't they. You can't return one of those in
> any SQL function or column name.
Doing textout(byteaout(... really makes no sense. But being
able to do a textin(mytypeout(... does make sense for me.
Without that, there MUST be type casting support for
MYTYPE->TEXT in the parser.
Sometimes ppl implement user defined types. I assume this
kind of type casting is used somewhere in a couple of
applications.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
wieck@debis.com (Jan Wieck) writes:
>>>> For that matter, why do we allow user expressions to call the type
>>>> input/output functions at all? They're not really usable as SQL
>>>> functions AFAICS...
> Doing textout(byteaout(... really makes no sense. But being
> able to do a textin(mytypeout(... does make sense for me.
> Without that, there MUST be type casting support for
> MYTYPE->TEXT in the parser.
The real problem here is that the type system needs to have a notion
of "C string" as a datatype so that the type input and output functions
can be declared *properly* with the true nature of their inputs and
results given correctly. Then typeain(typebout(typebvalue)) would work
and textout(byteaout(...)) would be rejected, as it should be.
The typechecking escape convention (zero in the proargtypes signature)
should only be used for functions that really do accept any kind of
datum. I think there are some (count(*) for one) but not many.
The "C string" type is not quite a real type, because we don't want to
let people declare columns of that type (I assume). OTOH it must be
real enough to let people declare user-defined functions that accept or
return it. Right now, the I/O functions for user-defined types are
supposed to be declared to take or return type OPAQUE, but I think
that pseudo-type is being used for too many different things.
Obviously none of this is going to happen for 6.5, but it should go
on the TODO list.
regards, tom lane
Added to TODO: * Fix typein/out functions to not be user-callable > David Sauer <davids@orfinet.cz> writes: > > david=> select textout(byteaout(odata)) from xinv18986; > > pqReadData() -- backend closed the channel unexpectedly. > > I think this is not related to large objects per se --- it's a > typechecking failure. textout is expecting a text datum, and it's > not getting one because that's not what comes out of byteaout. > (The proximate cause of the crash is that textout tries to interpret > the first four bytes of byteaout's output as a varlena length...) > > The parser's typechecking machinery is unable to catch this > error because textout is declared to take any parameter type > whatever (its proargtype is 0). > > Why don't the type output functions have the correct input types > declared for them in pg_proc??? > > For that matter, why do we allow user expressions to call the type > input/output functions at all? They're not really usable as SQL > functions AFAICS... > > regards, tom lane > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Removed from TODO list: * Fix typein/out functions to not be user-callable > > > For that matter, why do we allow user expressions to call the type > > > input/output functions at all? They're not really usable as SQL > > > functions AFAICS... > > > > Yes, they take C pointers, don't they. You can't return one of those in > > any SQL function or column name. > > Doing textout(byteaout(... really makes no sense. But being > able to do a textin(mytypeout(... does make sense for me. > Without that, there MUST be type casting support for > MYTYPE->TEXT in the parser. > > Sometimes ppl implement user defined types. I assume this > kind of type casting is used somewhere in a couple of > applications. > > > Jan > > -- > > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #======================================== jwieck@debis.com (Jan Wieck) # > > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Re-added to TODO list :-) * Fix typein/out functions to not be user-callable > wieck@debis.com (Jan Wieck) writes: > >>>> For that matter, why do we allow user expressions to call the type > >>>> input/output functions at all? They're not really usable as SQL > >>>> functions AFAICS... > > > Doing textout(byteaout(... really makes no sense. But being > > able to do a textin(mytypeout(... does make sense for me. > > Without that, there MUST be type casting support for > > MYTYPE->TEXT in the parser. > > The real problem here is that the type system needs to have a notion > of "C string" as a datatype so that the type input and output functions > can be declared *properly* with the true nature of their inputs and > results given correctly. Then typeain(typebout(typebvalue)) would work > and textout(byteaout(...)) would be rejected, as it should be. > > The typechecking escape convention (zero in the proargtypes signature) > should only be used for functions that really do accept any kind of > datum. I think there are some (count(*) for one) but not many. > > The "C string" type is not quite a real type, because we don't want to > let people declare columns of that type (I assume). OTOH it must be > real enough to let people declare user-defined functions that accept or > return it. Right now, the I/O functions for user-defined types are > supposed to be declared to take or return type OPAQUE, but I think > that pseudo-type is being used for too many different things. > > Obviously none of this is going to happen for 6.5, but it should go > on the TODO list. > > regards, tom lane > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Re-added to TODO list :-)
> * Fix typein/out functions to not be user-callable
Please rephrase it:
* Declare typein/out functions in pg_proc with a special "C string" data type
We want to type-check their uses correctly, not forbid their use.
regards, tom lane
>> The real problem here is that the type system needs to have a notion
>> of "C string" as a datatype so that the type input and output functions
>> can be declared *properly* with the true nature of their inputs and
>> results given correctly. Then typeain(typebout(typebvalue)) would work
>> and textout(byteaout(...)) would be rejected, as it should be.
>>
>> The typechecking escape convention (zero in the proargtypes signature)
>> should only be used for functions that really do accept any kind of
>> datum. I think there are some (count(*) for one) but not many.
>>
>> The "C string" type is not quite a real type, because we don't want to
>> let people declare columns of that type (I assume). OTOH it must be
>> real enough to let people declare user-defined functions that accept or
>> return it. Right now, the I/O functions for user-defined types are
>> supposed to be declared to take or return type OPAQUE, but I think
>> that pseudo-type is being used for too many different things.
>>
>> Obviously none of this is going to happen for 6.5, but it should go
>> on the TODO list.
>>
>> regards, tom lane