From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, tgl(at)sss(dot)pgh(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.4.1 release |
Date: | 1998-12-11 14:43:27 |
Message-ID: | 199812111443.XAA00651@ext16.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I think at least large object stuffs should be fixed(just a "select
> > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been
> > looking into codes for sometime but have not found complete fixes yet.
>
> I thought we already had a large object fix in the two trees already?
So you fixed inv_api.c? I got cvs header in REL6_4 tree (FreeBSD
2.2.6-RELEASE). Is this the latest one?
* $Header: /usr/local/cvsroot/pgsql/src/backend/storage/large_object/in\
v_api.c,v 1.41 1998/10/06 03:55:43 momjian Exp $
Following is a backend-crashing example. Any idea?
(/tmp/html.tar.gz is a 102458 bytes long file)
> select lo_import('/tmp/html.tar.gz');
blank
1: lo_import (typeid = 26, len = 4, typmod = -1, byval = t)
----
Program received signal SIGSEGV, Segmentation fault.
0x9dc75 in ReleaseBuffer ()
(gdb) where
#0 0x9dc75 in ReleaseBuffer ()
#1 0xa20b3 in inv_write ()
#2 0x4605f in lo_import ()
#3 0xd84a9 in fmgr_c ()
#4 0x3b06a in ExecMakeFunctionResult ()
#5 0x3b107 in ExecEvalFunc ()
#6 0x3b3c9 in ExecEvalExpr ()
#7 0x3b5e6 in ExecTargetList ()
#8 0x3b79a in ExecProject ()
#9 0x4139d in ExecResult ()
#10 0x39c66 in ExecProcNode ()
#11 0x392c6 in ExecutePlan ()
#12 0x38cf1 in ExecutorRun ()
#13 0xaad5b in ProcessQueryDesc ()
#14 0xaadc6 in ProcessQuery ()
#15 0xa8d8e in pg_exec_query_dest ()
#16 0xa8c24 in pg_exec_query ()
#17 0xaa598 in PostgresMain ()
#18 0x4c16c in main ()
(gdb)
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1998-12-11 14:53:58 | Re: [PATCHES] [REL6_4] pg_dumpall & binary cursor fix in MB support |
Previous Message | Terry Mackintosh | 1998-12-11 14:42:54 | Inclusion of spi mod. date. function? |