RE: [HACKERS] Suggested change in include/utils/elog.h
If you do decide to prefix DEBUG, please consider prefixing at least ERROR as well. It produces a lot of warnings when compiling on Win32 (ERROR is already defined as part of the standard windows headers). It's just warnings, though. //Magnus > Do other people have a comment on this. I am inclined to leave it > along. This is the first complaint I have heard, and > elog(PGDEBUG) just > looks funny. We don't prefix NOTICE or ERROR. > > > > In the file > > > >include/utils/elog.h > > > > there is a macro named > > > >DEBUG > > > > that conflicts with the perl5.6 macro DEBUG. > > > > PostgreSQL would probably "play" better with other products if > > the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar. > > > > Until there is some fix in this area, plperl will not build with > > a version of perl that has debugging enabled. > > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, > Pennsylvania 19026 >
Re: [HACKERS] SIGSEGV in postgres 7.0.0 for QNX
Sorry for the delay but I can't find gdb. I already looked at the doc/FAQ_QNX4 file but I didn't find any help. At the moment I'm tring to fix the problem, also with the QNX italian reseller, but we can't undestand if the problem is the QNX configuration or the PGSQL QNX version. Today I also tried POSTGRES 7.0.2 but I obtained the same error. Please could you give me any other ideas to fix the problem ? Thanks. Maurizio Cauci www.dreamtech-it.com - Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "Maurizio" <[EMAIL PROTECTED]> Cc: "PostgreSQL Development" <[EMAIL PROTECTED]> Sent: Monday, September 18, 2000 9:57 PM Subject: Re: [HACKERS] SIGSEGV in postgres 7.0.0 for QNX > Maurizio writes: > > > The only commad that I can execute is initdb. > > > > When I execute any other command I have a SIGSEGV error. > > > Attached is a log file with the error. > > I see no attachments to your post. You should look at the file > doc/FAQ_QNX4 if you haven't already. It seems that choosing a working > compiler is non-trivial on QNX. Also, configure with --enable-debug and > generate a stack trace from the failing program, e.g., > > $ /usr/local/pgsql/bin/psql > Segementation fault (core dumped) > $ gdb /usr/local/pgsql/bin/psql core > ... > (gdb) bt > [ output here ] > > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ >
[HACKERS] Solaris configure problems.
Hi, There seems to be a problem in the configure script for solaris. (Recent CVS copy) ./configure checking for POSIX signal interface... (cached) yes ./configure: syntax error at line 6907: `;' unexpected A "for" construct, traced back to config/tcl.m4, is upsetting the shell interpreter. The construct.. for pgac_dir; do if test -r "$pgac_dir/tclConfig.sh"; then TCL_CONFIG_SH=$pgac_dir/tclConfig.sh break fi done fails, but.. for pgac_dir do if test -r "$pgac_dir/tclConfig.sh"; then TCL_CONFIG_SH=$pgac_dir/tclConfig.sh break fi done is OK. I think either should be OK, indeed bash is happy with both. Perhaps we could change to the latter to keep Solaris happy? BTW: On the latest CVS, a couple of the changed regression tests fail because the solaris specific "expected" files don't match the new results. Do you want me to supply diffs to bring them upto date? Thanks, Keith. --
Re: [HACKERS] Solaris configure problems.
Keith Parks writes: > for pgac_dir; do > if test -r "$pgac_dir/tclConfig.sh"; then > TCL_CONFIG_SH=$pgac_dir/tclConfig.sh > break > fi > done > > fails Thanks. The semicolon is actually only needed (allowed) with an `in' clause. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Crash during vacuum analyze only...
I have a table. When I vacuum verbose it... mail=# vacuum verbose tblemaildomain ; NOTICE: --Relation tblemaildomain-- NOTICE: Pages 199: Changed 0, reaped 0, Empty 0, New 0; Tup 27494: Vac 0, Keep/VTL 1/0, Crash 0, UnUsed 0, MinLen 40, MaxLen 80; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.02u sec. NOTICE: Index tblemaildomain_pkey: Pages 70; Tuples 27494. CPU 0.00s/0.03u sec. NOTICE: Index tblemaildomain_oid: Pages 70; Tuples 27494. CPU 0.00s/0.04u sec. VACUUM When I vacuum verbose analyze it... mail=# vacuum verbose analyze tblemaildomain ; NOTICE: --Relation tblemaildomain-- FATAL 1: Memory exhausted in AllocSetAlloc() pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded. Thoughts/solutions? Thanks... - K Kristofer Munn * KMI * 732-254-9305 * AIM KrMunn * http://www.munn.com/