Обсуждение: error status 139
Hi all, My backend is terminating and I am getting the following error message in the log file: Server process (pid 29620) exited with status 139 at Fri Jul 20 17:14:31 2001 Terminating any active server processes... Server processes were terminated at Fri Jul 20 17:14:31 2001 Any idea what status 139 indicates? Thanks, -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere
Laurette Cisneros <laurette@nextbus.com> writes:
> Any idea what status 139 indicates?
SIGSEGV core dump, on most systems. Look for the backend core file
(in $PGDATA/base/yourdb/core) and send us a gdb stack trace ...
also, it would help to know what PG version you are running, on
what platform, and what you were doing when the crash happened.
regards, tom lane
Hello all: Sorry for the bad subject line on the last version of this post. I'm trying to load about 10M rows of data into a simple postgres table. The data is straightforward and fairly clean, but does have glitches every few tens of thousands of rows. My problem is that when COPY hits a bad row it just aborts, leaving me to go back, delete or clean up the row and try again. Is there any way to import records that could just skip the bad ones and notify me which ones they are? Loading this much data is pretty time-consuming, especially when I keep having to repeat it to find each new bad row. Is there a better way? -- sgl
Hello all: I'm trying to load about 10M rows of data into a simple postgres table. The data is straightforward and fairly clean, but does have glitches every few tens of thousands of rows. My problem is that when COPY hits a bad row it just aborts, leaving me to go back, delete or clean up the row and try again. Is there any way to import records that could just skip the bad ones and notify me which ones they are? Loading this much data is pretty time-consuming, especially when I keep having to repeat it to find each new bad row. Is there a better way? -- sgl
Hi Steve, I don't no of a direct method, e.g. turning off the 'die' behaviour of copy etc., but when I had the similar situation, I found it easier to just load the file in vi and clean the data first. Admittedly I only had a couple of hundred lines tho'. Alternatively, you could write a small parser in your favourite language (perl). Just turn on auto-comit, prepare the insert and then execute the prepared insert once per line. Write any line with a bad result to a seperate file. This file, you probably could just vi to update and re-run those lines throught the same script. Gary On Monday 23 July 2001 2:24 pm, Steven Lane wrote: > Hello all: > > Sorry for the bad subject line on the last version of this post. > > I'm trying to load about 10M rows of data into a simple postgres table. The > data is straightforward and fairly clean, but does have glitches every few > tens of thousands of rows. My problem is that when COPY hits a bad row it > just aborts, leaving me to go back, delete or clean up the row and try > again. > > Is there any way to import records that could just skip the bad ones and > notify me which ones they are? Loading this much data is pretty > time-consuming, especially when I keep having to repeat it to find each new > bad row. Is there a better way? > > -- sgl > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
Thanks for the help...
I am using vers. 7.1.2 of PostgreSQL on Redhat Linux 7.1 (2.4 kernel). I am running a set of external functions (in C)
thatare dynamincally loaded when needed (in a .so) that do some computations on rows. It works fine if I do a few
rows,but crashes when done ni "batch" (a large set of rows).
My C is rusty and any help you can give is greatly appreciated.
Thannks!
Here's the stack track from the core file:
#0 0x4013275a in _IO_vfprintf (s=0x0,
format=0x4001966f "nbpointdist\n", ap=0xbfffe860)
at vfprintf.c:270
#1 0x4013c445 in fprintf (stream=0x0,
format=0x4001966f "nbpointdist\n") at fprintf.c:32
#2 0x40018e44 in nbpointdist () at eval.c:41
#3 0x40018d43 in dpath () at eval.c:41
#4 0x081463be in fmgr_oldstyle (fcinfo=0x82f8e04) at fmgr.c:448
#5 0x080d04ed in ExecMakeFunctionResult (fcache=0x82f8df0,
arguments=0x82efb08, econtext=0x82ef0e8,
isNull=0x82f12ad "", isDone=0xbfffe9a4) at execQual.c:807
#6 0x080d058e in ExecEvalFunc (funcClause=0x82efab8,
econtext=0x82ef0e8, isNull=0x82f12ad "", isDone=0xbfffe9a4)
at execQual.c:901
#7 0x080d095c in ExecEvalExpr (expression=0x82efab8,
econtext=0x82ef0e8, isNull=0x82f12ad "", isDone=0xbfffe9a4)
at execQual.c:1226
#8 0x080d0338 in ExecEvalFuncArgs (fcache=0x82f1248,
argList=0x82efaa0, econtext=0x82ef0e8) at execQual.c:614
#9 0x080d03b1 in ExecMakeFunctionResult (fcache=0x82f1248,
arguments=0x82efaa0, econtext=0x82ef0e8,
isNull=0xbfffea57 "", isDone=0xbfffea58) at execQual.c:667
#10 0x080d058e in ExecEvalFunc (funcClause=0x82efa50,
econtext=0x82ef0e8, isNull=0xbfffea57 "", isDone=0xbfffea58)
at execQual.c:901
#11 0x080d095c in ExecEvalExpr (expression=0x82efa50,
econtext=0x82ef0e8, isNull=0xbfffea57 "", isDone=0xbfffea58)
at execQual.c:1226
#12 0x080d0bfb in ExecTargetList (targetlist=0x82efb78,
nodomains=6, targettype=0x82f0c08, values=0x82f0fa0,
econtext=0x82ef0e8, isDone=0xbfffec28) at execQual.c:1547
#13 0x080d0e55 in ExecProject (projInfo=0x82f0f78,
isDone=0xbfffec28) at execQual.c:1775
#14 0x080d59fa in ExecNestLoop (node=0x82ef9b0)
at nodeNestloop.c:245
#15 0x080cf7a6 in ExecProcNode (node=0x82ef9b0, parent=0x82ef9b0)
at execProcnode.c:297
#16 0x080ceafe in ExecutePlan (estate=0x82efd60, plan=0x82ef9b0,
operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x82f10d0)
at execMain.c:974
#17 0x080ce073 in ExecutorRun (queryDesc=0x82efd48,
estate=0x82efd60, feature=3, count=0) at execMain.c:233
#18 0x0810ef73 in ProcessQuery (parsetree=0x8287840,
plan=0x82ef9b0, dest=Remote) at pquery.c:295
#19 0x0810db7b in pg_exec_query_string (
query_string=0x82866f0 "\n SELECT \n nbdist2point(p.path_points, dpath(p.path_points),
s.path_position)AS nbdist2point,\n", ' ' <repeats 15 times>, "s.stop_tag, s.dir_tag, s.path_tag, \n", ' ' <repeats 15
times>,"s.path_position, s.stop_o"...,
dest=Remote, parse_context=0x826a978) at postgres.c:810
#20 0x0810eaa6 in PostgresMain (argc=4, argv=0xbfffef08,
real_argc=4, real_argv=0xbffff83c,
username=0x82585b1 "laurette") at postgres.c:1908
#21 0x080fa503 in DoBackend (port=0x8258348) at postmaster.c:2114
#22 0x080fa0ec in BackendStartup (port=0x8258348)
at postmaster.c:1897
#23 0x080f93c6 in ServerLoop () at postmaster.c:995
#24 0x080f8d93 in PostmasterMain (argc=4, argv=0xbffff83c)
at postmaster.c:685
#25 0x080dcd55 in main (argc=4, argv=0xbffff83c) at main.c:175
#26 0x400fae5e in __libc_start_main (main=0x80dcc40 <main>,
argc=4, ubp_av=0xbffff83c, init=0x807dec0 <_init>,
fini=0x81aeb7c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbffff834) at ../sysdeps/generic/libc-start.c:129
On Sat, 21 Jul 2001, Tom Lane wrote:
> Laurette Cisneros <laurette@nextbus.com> writes:
> > Any idea what status 139 indicates?
>
> SIGSEGV core dump, on most systems. Look for the backend core file
> (in $PGDATA/base/yourdb/core) and send us a gdb stack trace ...
> also, it would help to know what PG version you are running, on
> what platform, and what you were doing when the crash happened.
>
> regards, tom lane
>
--
Laurette Cisneros
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
Passenger Information Everywhere
Here's more info I was able to track down...
I am making a function call to a c function in my SQL, example:
SELECT funct(arg) FROM x;
Here's the create statment for function func:
CREATE FUCNTION func(path)
RETURNS point
AS '${PGLIB}/xxx.so' LANGUAGE 'c';
Inside the c function funct, when a certain condition arises:
...
return NULL;
This is what the backend is SEGVing on, when a NULL gets returned for the function (for the Point type).
Is this correct behaviour of the backend? Is this how to return a null value for a Point type?
THanks,
L.
On Sat, 21 Jul 2001, Tom Lane wrote:
> Laurette Cisneros <laurette@nextbus.com> writes:
> > Any idea what status 139 indicates?
>
> SIGSEGV core dump, on most systems. Look for the backend core file
> (in $PGDATA/base/yourdb/core) and send us a gdb stack trace ...
> also, it would help to know what PG version you are running, on
> what platform, and what you were doing when the crash happened.
>
> regards, tom lane
>
--
Laurette Cisneros
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
Passenger Information Everywhere
Laurette Cisneros <laurette@nextbus.com> writes:
> Here's the stack track from the core file:
> #1 0x4013c445 in fprintf (stream=0x0,
> format=0x4001966f "nbpointdist\n") at fprintf.c:32
Sure looks like you're trying to write on a non-open file (stream=0
suggests you're passing a NULL file pointer to fprintf).
As for your later message, no you can't return an SQL NULL by
returning a NULL pointer. The only way to return NULLs cleanly
is to use the v1 function call interface, within which the macro
PG_RETURN_NULL() works. See the documentation about writing C
functions.
regards, tom lane
Hi Tom, Thanks for getting back to me. I did discover both of these things in my debuggng efforts. The PG_RETURN_NULL() macro doesn'taccomodate a Point type very easily (that I can see), but I think I'll just raise an error for a situation where aNULL would be returned. Thanks again, Laurette On Tue, 24 Jul 2001, Tom Lane wrote: > Laurette Cisneros <laurette@nextbus.com> writes: > > Here's the stack track from the core file: > > #1 0x4013c445 in fprintf (stream=0x0, > > format=0x4001966f "nbpointdist\n") at fprintf.c:32 > > Sure looks like you're trying to write on a non-open file (stream=0 > suggests you're passing a NULL file pointer to fprintf). > > As for your later message, no you can't return an SQL NULL by > returning a NULL pointer. The only way to return NULLs cleanly > is to use the v1 function call interface, within which the macro > PG_RETURN_NULL() works. See the documentation about writing C > functions. > > regards, tom lane > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere