Re: [BUGS] Conversion errors for datetime fields
* Bruce Momjian <[EMAIL PROTECTED]> [010102 01:49]: > > Looking at Page 166 of "SQL-99 Complete, Really" by Peter Gulutzan & > > Trudy Peltzer, R&D Books, ISBN 0-87930-568-1, 1st bullet: > > That is a strange name for a book. :-) They explain the title as meaning they don't refer you off to another book for SQL stuff. It's actually a nice book. However, given the discussion Tom and I had on-list, I really need to get a REAL copy of the standard someday. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [BUGS] AIX 4.3.1, 7.0.3 build annoyances: C++ comments, make all, macro problem
"Travis W. Pouarz" <[EMAIL PROTECTED]> writes: > Does the regression test the optional interfaces such as tcl and odbc? No, just the core code (and even there, the coverage is pretty limited, but it's a lot better than nothing...) > Here are the fails: > timestamp... FAILED > test geometry ... FAILED > test horology ... FAILED Hm. There is a geometry variant expected file for AIX: geometry/powerpc.*-aix4=geometry-powerpc-aix4 Does your results file happen to match expected/geometry-powerpc-aix4.out, or any of the other existing geometry-foo expected files? If so, why isn't this resultmap file matching your platform? (Check what config.guess prints...) > That 0 / -0 mismatch might cause some people some trouble. Not a big problem, I don't think. We have some platforms where -0 always prints without the minus sign anyway. > The timestamp and horology differences were all diffences > of one-hour where I get one hour less than the expected. I'd > guess that your expected assumes running in EST and I'm > in CST. No, the expecteds are PST8PDT, and the regression script should force TZ to PST8PDT as well. You may have one of the platforms that has weird ideas about PDT times before 1970. Or maybe it's been fixed since the AIX version that Andreas uses. I see entries in resultmap that change the expected file for AIX: horology/.*-aix4=horology-1947-PDT Perhaps these are triggering but are not appropriate for your version of AIX. If you want to see this cleaned up, please read http://www.postgresql.org/devel-corner/docs/postgres/regress.htm http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm and then submit proposed diffs for the resultmap (and new expected files if necessary). regards, tom lane
[BUGS] PostgreSQL 7.0.3: Memory leak in ESQL library
Hello, I've found a memory leak in libecpg of PostgreSQL 7.0.3. The leak is caused by the memory allocation in src/interfaces/ecpg/lib/execute.c in line 669 which is never freed. Adding a "free(array_query);" after PQexec in line 671 seems to fix the leak. Regards Thorsten -- E-Mail: [EMAIL PROTECTED] ___ WWW: http://tek.thorsten-knabe.de || /ICQ: 5472045 |horsten |/\nabe Linux AD1816 sound driver developer
Re: [BUGS] AIX 4.3.1, 7.0.3 build annoyances: C++ comments, make all, macro problem
On Mon, 1 Jan 2001, Tom Lane wrote: > Running the regression tests (src/test/regress) would be a more thorough > test that things are working. Right. Does the regression test the optional interfaces such as tcl and odbc? Here are the fails: timestamp... FAILED test geometry ... FAILED test horology ... FAILED The geometry fails appear to be because of differences in the extremes of floating point precision, except for this case: *** ./expected/geometry.out Wed Sep 13 02:00:17 2000 --- ./results/geometry.out Mon Jan 1 20:14:12 2001 *** *** 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) That 0 / -0 mismatch might cause some people some trouble. The timestamp and horology differences were all diffences of one-hour where I get one hour less than the expected. I'd guess that your expected assumes running in EST and I'm in CST. -Travis
Re: [BUGS] AIX 4.3.1, 7.0.3 build annoyances: C++ comments, makeall, macro problem
Travis W. Pouarz writes:
> ar crs libpgtcl.a pgtcl.o pgtclCmds.o pgtclId.o
> touch libpgtcl.a
> ../../../src/backend/port/aix/mkldexport.sh libpgtcl.a > libpgtcl.exp
> cc -O -qtune=p2sc -qmaxmem=8192 -Wl,-H512 -Wl,-bM:SRE
> -Wl,-bI:../../../src/backend/postgres.imp -Wl,-bE:libpgtcl.exp -o
> libpgtcl.so libpgtcl.a
> -L/.../austin.ibm.com/fs/projects/gsys/pkg/readline-4.1/lib
> -L/.../austin.ibm.com/fs/projects/gsys/lib
> -L/.../austin.ibm.com/fs/projects/gsys/pkg/readline-4.1/lib
> -L/.../austin.ibm.com/fs/projects/gsys/lib
> -L../../../src/interfaces/libpq -lpq -lc
> ...
> ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetVar2
> ld: 0711-317 ERROR: Undefined symbol: .Tcl_SetVar
> ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendResult
> ld: 0711-317 ERROR: Undefined symbol: .Tcl_Preserve
> ...
On other platforms it is not an error if a shared library link leaves
unresolved symbols. (I'm not totally convinced whether this is desirable,
but that's the way we have set them up.) On AIX >=4 it should work to add
the option -Wl,-berok ("external references okay") at an opportune place
in src/makefiles/Makefile.aix. Please try that.
> so I added -ltcl8.0 to LDFLAGS in src/Makefile.global:
Hmm, I guess one reason that this is not done by default is to allow using
libpgtcl with various Tcl versions, to be decided at the time the
executable is linked. Not sure if this is really feasible, though.
> /.../austin.ibm.com/fs/projects/gsys/lib/tcl8.0/ldAix /bin/ld -bhalt:4
> -bM:SRE -bE:lib.exp -H512 -T512 -bnoentry -o pltcl.so pltcl.o
> -L/.../austin.ibm.com/fs/projects/gsys/lib -ltcl8.0 -lld -lm -lbsd -lc
> noDotA="pltcl.so"
> ld: 0711-317 ERROR: Undefined symbol: .nocachegetattr
> ld: 0711-317 ERROR: Undefined symbol: .heap_getsysattr
> ld: 0711-317 ERROR: Undefined symbol: .SearchSysCache
> ld: 0711-317 ERROR: Undefined symbol: .elog
> ld: 0711-317 ERROR: Undefined symbol: .ReleaseSysCache
> ld: 0711-317 ERROR: Undefined symbol: .OidFunctionCall3
> ld: 0711-317 ERROR: Undefined symbol: .pfree
> ld: 0711-317 ERROR: Undefined symbol: Warn_restart
> ld: 0711-317 ERROR: Undefined symbol: .FunctionCall3
> ld: 0711-317 ERROR: Undefined symbol: .SPI_execp
> ld: 0711-317 ERROR: Undefined symbol: SPI_processed
> ld: 0711-317 ERROR: Undefined symbol: SPI_tuptable
> ...
Okay, same answer as above here really, but unfortunately we're using the
magic flags provided by Tcl here, so either we override them (or augment
them) in the AIX case, or we do something like
> so I added -bI:/tmp/postgresql-snapshot/src/backend/postgres.imp to TCL_SHLIB_LD
> in src/pl/tcl/Makefile.tcldefs:
The -Wl,-berok will lose on AIX 3*, so if anyone cares run run PG with Tcl
on that platform we'll have to think harder.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [BUGS] PostgreSQL 7.0.3: Memory leak in ESQL library
Yes, I see the problem you reported. Here is the patch I have applied.
Thanks.
> Hello,
>
> I've found a memory leak in libecpg of PostgreSQL 7.0.3.
> The leak is caused by the memory allocation in
> src/interfaces/ecpg/lib/execute.c in line 669 which is never freed.
> Adding a "free(array_query);" after PQexec in line 671 seems to fix the
> leak.
>
> Regards
> Thorsten
>
> --
> E-Mail: [EMAIL PROTECTED]
> ___ WWW: http://tek.thorsten-knabe.de
> || /ICQ: 5472045
> |horsten |/\nabe Linux AD1816 sound driver developer
>
>
--
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
? config.log
? config.cache
? config.status
? GNUmakefile
? doc/src/sgml/ttypd
? src/Makefile.custom
? src/GNUmakefile
? src/Makefile.global
? src/log
? src/crtags
? src/backend/postgres
? src/backend/catalog/global.description
? src/backend/catalog/global.bki
? src/backend/catalog/template1.bki
? src/backend/catalog/template1.description
? src/backend/port/Makefile
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_config/pg_config
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/pg_dump
? src/bin/pg_dump/pg_restore
? src/bin/pg_dump/pg_dumpall
? src/bin/pg_id/pg_id
? src/bin/pg_passwd/pg_passwd
? src/bin/pgaccess/pgaccess
? src/bin/pgtclsh/Makefile.tkdefs
? src/bin/pgtclsh/Makefile.tcldefs
? src/bin/pgtclsh/pgtclsh
? src/bin/pgtclsh/pgtksh
? src/bin/psql/psql
? src/bin/scripts/createlang
? src/include/config.h
? src/include/stamp-h
? src/interfaces/ecpg/lib/libecpg.so.3.2.0
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpgeasy/libpgeasy.so.2.1
? src/interfaces/libpgtcl/libpgtcl.so.2.1
? src/interfaces/libpq/libpq.so.2.1
? src/interfaces/perl5/blib
? src/interfaces/perl5/Makefile
? src/interfaces/perl5/pm_to_blib
? src/interfaces/perl5/Pg.c
? src/interfaces/perl5/Pg.bs
? src/pl/plperl/blib
? src/pl/plperl/Makefile
? src/pl/plperl/pm_to_blib
? src/pl/plperl/SPI.c
? src/pl/plperl/plperl.bs
? src/pl/plpgsql/src/libplpgsql.so.1.0
? src/pl/tcl/Makefile.tcldefs
Index: src/interfaces/ecpg/lib/execute.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/ecpg/lib/execute.c,v
retrieving revision 1.15
diff -c -r1.15 execute.c
*** src/interfaces/ecpg/lib/execute.c 2000/12/18 11:33:54 1.15
--- src/interfaces/ecpg/lib/execute.c 2001/01/02 22:00:08
***
*** 341,346
--- 341,347
array_query = (char *) ecpg_alloc(strlen("select typelem from pg_type where
oid=") + 11, stmt->lineno);
sprintf(array_query, "select typelem from pg_type where oid=%d", type);
query = PQexec(stmt->connection->connection, array_query);
+ free(array_query);
if (PQresultStatus(query) == PGRES_TUPLES_OK)
{
isarray = atol((char *) PQgetvalue(query, 0, 0));
Re: [BUGS] vacuum analyze fails with latest cvs version
On Mon, 1 Jan 2001, Tom Lane wrote:
>[EMAIL PROTECTED] writes:
>> Problem 1: "vacuum messages;" works but "vacuum analyze messages;"
>> kills the backend.
>
>We have absolutely no hope of responding to a bug report with only
>that amount of information. How about a backtrace from the core
>file? How about telling us the schema for the table that's causing
>the problem?
(gdb) bt
#0 0x40269e80 in strcoll () at strcoll.c:228
#1 0x812301a in varstr_cmp ()
#2 0x8123067 in text_cmp ()
#3 0x812309a in text_lt ()
#4 0x8135036 in FunctionCall2 ()
#5 0x80acffd in attr_stats ()
#6 0x80acd19 in analyze_rel ()
#7 0x80a91fe in vac_vacuum ()
#8 0x80a916d in vacuum ()
#9 0x80fc06f in ProcessUtility ()
#10 0x80fa119 in pg_exec_query_string ()
#11 0x80fb02a in PostgresMain ()
#12 0x80e64e8 in DoBackend ()
#13 0x80e60b7 in BackendStartup ()
#14 0x80e52e5 in ServerLoop ()
#15 0x80e4ce6 in PostmasterMain ()
#16 0x80c6818 in main ()
Table "messages"
Attribute | Type| Modifier
mid | integer | not null default nextval('msg_id'::text)
lid | integer |
sender| text |
date | timestamp |
subject | text |
body | text |
Index: messages_index
Index "messages_index"
Attribute | Type
---+-
lid | integer
mid | integer
btree
select count(*) from messages;
count
---
18667
select max(length(body)) from messages;
max
---
92148
(1 row)
This is from the stderr of the backend: (it dies on "messages" even
it doesn't show up here)
DEBUG: Index pg_toast_18752_idx: Pages 34; Tuples 7681. CPU 0.05s/0.03u
sec.
DEBUG: Analyzing...
Server process (pid 9850) exited with status 139 at Mon Jan 1 01:43:08
2001
Terminating any active server processes...
Server processes were terminated at Mon Jan 1 01:43:08 2001
I didn't compile the thingy with --enable-debug, I can try with that
too, if required?
...
Jukka Honkela
