Re: Trouble with plpgsql on 7.4.6

From: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Trouble with plpgsql on 7.4.6
Date: 2004-11-23 15:59:18
Message-ID: 20041123155918.GR24971@quartz.newn.cam.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 23, 2004 at 07:25:17AM -0500, D'Arcy J.M. Cain wrote:
> The stderr was in the previous message. No gripes there either other
> than in the startup after the failure.
>
> > Also see about getting a stack trace from one of the core dumps.
>
> I did look at the core file and here is what I saw:
>
> #0 0x483cafeb in kill () from /usr/lib/libc.so.12
> #1 0x483cd0af in __libc_mutex_catchall_stub (m=1212478892)
> at /usr/src/lib/libc/thread-stub/thread-stub.c:112
> #2 0x4843f0f7 in free (ptr=<incomplete type>)
> at /usr/src/lib/libc/stdlib/malloc.c:1149
> #3 0x081b3efc in AllocSetDelete (context=<error type>) at aset.c:464
> #4 0x081b468a in MemoryContextDelete (context=<error type>) at
> #mcxt.c:192

Would setting the following environment variable get you an earlier
abort / more logging? (pthread(3))

PTHREAD_DIAGASSERT Possible values are any combinations of:
A Ignore errors.
a Abort on errors, creating a core
dump for further debugging.
E Do not log errors to stdout.
e Log errors to stdout.
L Do not log errors via
syslogd(8).
l Log errors via syslogd(8).

Cheers,

Patrick

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-11-23 16:33:15 Re: Beta5 now Available
Previous Message Tom Lane 2004-11-23 15:33:50 Re: patch: plpgsql - access records with rec.(expr)