[BUGS] Creating trigger function with argument(s) gets backend crash.
Hi all, When I attempted to create a trigger function with argument(s), the backend got crashed. I know this operation is wrong, however I think the backend crash mustn't be occured, it should be a syntax error or something like that. Is this a bug, or just my mistake(or misunderstanding)? Now I'm working on CVS tree retreived on 2005/07/01. Thanks. snaga=# CREATE FUNCTION t1_trig_func(integer) RETURNS trigger snaga-# AS ' snaga'# BEGIN snaga'# RAISE NOTICE ''foo''; snaga'# END snaga'# ' LANGUAGE 'plpgsql'; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> \q -- NAGAYASU Satoshi <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Error installing Postgres on Solaris 9
Hi,
when I run: ./configure --without-readline, I get errors that aborts the configure
process: "checking types of arguments for accept()...
configure: error: could not determine argument types".
Please see following from the config.log.
Thanks,
Thanh
configure:10983: gcc -c -O2 -fno-strict-aliasing conftest.c >&5
In file included from /usr/include/netinet/in.h:41,
from /usr/include/sys/socket.h:203,
from configure:10963:
/usr/include/sys/stream.h:307: parse error before "projid_t"
configure:10965: parse error before "accept"
configure:10965: conflicting types for `accept'
/usr/include/sys/socket.h:450: previous declaration of `accept'
configure:10965: warning: data definition has no type or storage class
configure:10986: $? = 1
configure: failed program was:
#line 10958 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
extern unsigned int PASCAL accept (unsigned int, void *, socklen_t *);
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
;
return 0;
}
configure:10983: gcc -c -O2 -fno-strict-aliasing conftest.c >&5
In file included from /usr/include/netinet/in.h:41,
from /usr/include/sys/socket.h:203,
from configure:10963:
/usr/include/sys/stream.h:307: parse error before "projid_t"
configure:10965: parse error before "accept"
configure:10965: conflicting types for `accept'
/usr/include/sys/socket.h:450: previous declaration of `accept'
configure:10965: warning: data definition has no type or storage class
configure:10986: $? = 1
configure: failed program was:
#line 10958 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
extern unsigned int PASCAL accept (unsigned int, void *, unsigned int *);
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
;
return 0;
}
configure:10983: gcc -c -O2 -fno-strict-aliasing conftest.c >&5
In file included from /usr/include/netinet/in.h:41,
from /usr/include/sys/socket.h:203,
from configure:10963:
/usr/include/sys/stream.h:307: parse error before "projid_t"
configure:10965: parse error before "accept"
configure:10965: conflicting types for `accept'
/usr/include/sys/socket.h:450: previous declaration of `accept'
configure:10965: warning: data definition has no type or storage class
configure:10986: $? = 1
configure: failed program was:
#line 10958 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
extern unsigned int PASCAL accept (unsigned int, void *, void *);
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
;
return 0;
}
configure:11006: error: could not determine argument types
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1756: PQexec eats huge amounts of memory
The following bug has been logged online:
Bug reference: 1756
Logged by: Denis Vlasenko
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux
Description:PQexec eats huge amounts of memory
Details:
Verbatim from http://bugs.php.net/bug.php?id=33587:
Description:
Seen on php-4.3.4RC2. Since I was just testing how good
PG fares compared to Oracle, and I am not feeling any
real pain from this (IOW: not my itch to scratch),
I do not research this in depth, apart from submitting
bug report. Sorry.
Symptom: even the simplest query
$result = pg_query($db, "SELECT * FROM big_table");
eats enormous amounts of memory on server
(proportional to table size).
I think this is a problem with PostgreSQL client libs.
php's source is included for easy reference.
PHP_FUNCTION(pg_query)
{
...
pgsql_result = PQexec(pgsql, Z_STRVAL_PP(query));
if ((PGG(auto_reset_persistent) & 2) && PQstatus(pgsql) !=
CONNECTION_OK) {
PQclear(pgsql_result);
PQreset(pgsql);
pgsql_result = PQexec(pgsql, Z_STRVAL_PP(query));
}
if (pgsql_result) {
status = PQresultStatus(pgsql_result);
} else {
status = (ExecStatusType) PQstatus(pgsql);
}
switch (status) {
case PGRES_EMPTY_QUERY:
case PGRES_BAD_RESPONSE:
case PGRES_NONFATAL_ERROR:
case PGRES_FATAL_ERROR:
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Query failed: %s.", PQerrorMessage(pgsql));
PQclear(pgsql_result);
RETURN_FALSE;
break;
case PGRES_COMMAND_OK: /* successful command that did
not return rows */
default:
if (pgsql_result) {
pg_result = (pgsql_result_handle *)
emalloc(sizeof(pgsql_result_handle));
pg_result->conn = pgsql;
pg_result->result = pgsql_result;
pg_result->row = 0;
ZEND_REGISTER_RESOURCE(return_value,
pg_result, le_result);
} else {
PQclear(pgsql_result);
RETURN_FALSE;
}
break;
}
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] Creating trigger function with argument(s) gets backend crash.
On Wed, Jul 06, 2005 at 05:59:24PM +0900, Satoshi Nagayasu wrote: > > When I attempted to create a trigger function with argument(s), > the backend got crashed. Same here with the most recent HEAD. Here's a stack trace: #0 0xfed2f648 in plpgsql_compile (fcinfo=0xffbfdf38, forValidator=-32 'à') at pl_comp.c:688 #1 0xfed2d2a0 in plpgsql_validator (fcinfo=0x3bf5a4) at pl_handler.c:236 #2 0x00212b08 in OidFunctionCall1 (functionId=3929508, arg1=4290765752) at fmgr.c:1410 -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1756: PQexec eats huge amounts of memory
Denis, $result = pg_query($db, "SELECT * FROM big_table"); you are reading a big result (as I suspect from big_table) into memory. It is perfectly normal that this uses large amounts of memory. [it would be rather suspicious if loading a big file / big resultset would not use big amounts of memory] Harald -- GHUM Harald Massapersuasion python postgresqlHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607
Re: [BUGS] Creating trigger function with argument(s) gets backend crash.
Satoshi Nagayasu wrote: > Hi all, > > When I attempted to create a trigger function with argument(s), > the backend got crashed. > > I know this operation is wrong, however I think the backend crash > mustn't be occured, it should be a syntax error or something like that. > > Is this a bug, or just my mistake(or misunderstanding)? > > Now I'm working on CVS tree retreived on 2005/07/01. > > Thanks. > > snaga=# CREATE FUNCTION t1_trig_func(integer) RETURNS trigger > snaga-# AS ' > snaga'# BEGIN > snaga'# RAISE NOTICE ''foo''; > snaga'# END > snaga'# ' LANGUAGE 'plpgsql'; > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !> \q Yea, funny things is I saw the same crash last week when playing with something, and I assumed creating a function shouldn't make it crash, but I wasn't sure, so I didn't report it. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Creating trigger function with argument(s) gets backend crash.
Satoshi Nagayasu <[EMAIL PROTECTED]> writes: > When I attempted to create a trigger function with argument(s), > the backend got crashed. > Is this a bug, or just my mistake(or misunderstanding)? Definitely a bug; existing releases don't do that. Thanks for the report. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1756: PQexec eats huge amounts of memory
Denis Vlasenko wrote: Symptom: even the simplest query $result = pg_query($db, "SELECT * FROM big_table"); eats enormous amounts of memory on server (proportional to table size). Right, which is exactly what you would expect. The entire result set is sent to the client and stored in local memory; if you only want to process part of the result set at a time, use a cursor. (And I'm a little suspicious that the performance of "SELECT * FROM big_table" will contribute to a meaningful comparison between database systems.) -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
